No More Secrets: How I Built a Zero-Trust CI/CD Pipeline with GitHub Actions, Vault, and SPIRE

Let’s be honest: most CI/CD pipelines today are still scary from a security perspective.

I've seen access keys buried in YAML, secrets passed as plaintext env vars, and vault tokens that never expire. In an age of cloud-native infrastructure and Zero Trust, this feels… outdated.

So I challenged myself:
Can I build a full CI/CD pipeline where secrets are never statically stored and identity is the only trust anchor?

The result is a complete, cloud-agnostic Zero-Trust CI/CD framework that uses:

• GitHub Actions (as the runner)

• HashiCorp Vault (for short-lived secrets)

• SPIFFE/SPIRE (for workload identity)

• Terraform (to provision AWS & Azure infra)

Best part? It requires no hardcoded secrets and supports both AWS and Azure out of the box.

---

🎯 What I Wanted to Solve

Static secrets are a time bomb. Once leaked, they often stay valid for days or weeks. Rotating them is painful, especially across environments and teams.

Here’s what I really wanted:

• No long-lived secrets or access tokens

• Identity-first access control (no hardcoding AWS keys or Azure SPs)

• A clean separation of CI/CD and cloud trust

• A fully reproducible, modular repo that others can clone and use

---

🧩 The Tools I Used

• GitHub Actions: for CI/CD orchestration

• OIDC + GitHub’s built-in token issuer

• SPIRE: to issue workload identities using SPIFFE IDs

• HashiCorp Vault: to issue cloud credentials dynamically

• Terraform: to provision infra on AWS and Azure

• Bash scripts: to automate policy, role, and trust setup

Each tool plays a specific role. SPIRE handles identity issuance, Vault acts as the access broker, and Terraform ensures reproducibility.

---

🛠️ How It All Works (End-to-End Flow)

Let me break it down step-by-step:

1. A GitHub Actions workflow is triggered (e.g., on push to main)

2. GitHub signs an OIDC JWT for the workflow

3. The SPIRE server validates this JWT and issues a SPIFFE ID (e.g., spiffe://my-org/github-actions/deploy)

4. The CI job uses this identity to authenticate to Vault

5. Vault validates the identity and issues temporary credentials for AWS or Azure (based on policies and roles)

6. The job deploys using those credentials. When done, the secrets expire.

💡 There are no hardcoded tokens or keys involved at any step.

---

🗂️ Repo Structure

To keep it clean, I split the repo by cloud provider:

.
├── aws/
│   ├── spire/
│   ├── vault/
│   ├── terraform/
│   └── .github/workflows/
├── azure/
│   ├── spire/
│   ├── vault/
│   ├── terraform/
│   └── .github/workflows/

Each folder has:

• Complete configuration files and deployment scripts

• A detailed README.md with why, how, and what for every single file

• Realistic CI workflows using GitHub Actions

📌 For example:

• spire-server.conf and spire-agent.conf are fully configured for JWT SVID support

• Vault is configured to trust SPIFFE IDs and issue short-lived cloud credentials

• Terraform modules set up VMs, IAM roles, security groups, etc.

---

🔒 Real Zero-Trust, Not Just a Buzzword

This setup doesn’t just talk about Zero Trust — it applies it at every layer:

• Identity-first: GitHub workflows prove who they are via OIDC and SPIFFE

• No static secrets: All cloud access is granted dynamically through Vault

• Short-lived access: Secrets auto-expire after the job ends

• Platform-agnostic: Same flow works for AWS and Azure

You can easily extend it to GCP or Kubernetes later by reusing the SPIFFE + Vault pattern.

---

⚙️ Don’t Just Read — Clone and Explore

The repo is production-ready and self-contained. Anyone can clone it and:

• Explore each phase (SPIRE → Vault → Terraform → GitHub Actions)

• Learn how identity-based auth works in practice

• Customize it for their organization

🔗 GitHub Repo: https://github.com/amankc-neo/zero-trust-cicd-framework.git

---

✍️ Lessons Learned

This project was eye-opening. Here’s what stood out to me:

• Vault and SPIRE integrate beautifully if configured right

• GitHub’s native OIDC support is incredibly powerful

• Documentation matters — I took extra time to explain every config and decision

• Zero Trust CI/CD is very possible — and not that complex once you structure it well

---

🚀 Try It, Fork It, Break It

If you’re a DevOps engineer, platform SRE, or cloud security nerd — try this out.

I built this to be forkable and understandable. I want others to learn from it, build on it, and maybe even improve it.

Zero Trust doesn’t have to be a buzzword. This repo shows it can be the default posture for CI/CD.

Let me know what you think. I’d love feedback, pull requests, or just a message if you find it useful.

Thanks for reading! 🙌

---