If one principal can do anything, one mistake can undo everything.
I’ve read too many incident reviews where the “automation user” turned out to be the attacker’s best friend. One token. All the doors. Code, artifacts, production.
We built CI/CD to go fast. We accidentally made it the fastest path to a breach.
Just like with your human workforce, identity should be the control plane of your software factory. Treat it that way — or prepare for a very long night.
In this post I’ll cover the how and why of introducing identity into your CI/CD pipelines. I’ll present how you can use it today with the primitives provided in CI/CD and downstream resources, as well as how you can make it easier and automated with the use of Workload Identity and Access Management (Workload IAM).
What “Distinct Identity” Actually Means for CI/CD (and Why You Want It)
A secure pipeline doesn’t carry keys. It proves who it is — org, repo, branch, workflow, run — with distinct, cryptographically verifiable identity documentation, and then receives a just-in-time, short-lived credential to do exactly one job in exactly one environment. Then the credential expires. No “forever” tokens. No secret sprawl in vaults.
The mechanics aren’t exotic. Your CI platform (GitHub Actions, GitLab CI, Jenkins, etc.) typically can present those claims today, and the environment the platform runs on can provide those claims too. Your cloud can issue temporary creds for a narrow role (dev/stage/prod). Wire these things together consistently and you get three things for free: smaller blast radius, better forensics, and fewer 2 a.m. rotations.
We can go a little further: A Workload IAM layer (an identity control plane) makes the happy path standardized and automated. Same claim schema everywhere. Same TTL policy. Same least-privilege roles. One audit trail that says, unambiguously, which pipeline run touched which system and when. That’s not marketing. That’s operational sanity.
The standards guidance supports this direction: Read the NIST SSDF, NIST SP 800-204D, the NSA/CISA CI/CD hardening note, SLSA. The chorus is consistent — least privilege, isolation, provenance. None of that is real if your pipelines share a “build god” credential.
Distinct, time-boxed identities are how you implement the words we all agree on. A control plane turns them into reusable policy instead of one-off YAML and a hope that every repo maintainer remembers to copy it correctly.
This is also the natural bridge into how the common identity building blocks — such as OIDC, SPIFFE, and Workload IAM — fit together. We’ll also look at how each plays a role and why you often need them side by side.
Pearson 2025: One Token, Many Doors
In January, attackers got hold of a GitLab Personal Access Token (PAT). With that single thread, they pulled private repos and, like clockwork, found embedded credentials to widen access. The company disclosed the incident months later. No zero-day needed — just a long-lived, broadly scoped token tied to the software factory’s central nervous system.
With distinct, per-run identities and short TTLs, the first foothold would have had fewer doors to open. With an identity control plane, security would have had two levers that matter most in a crisis: an org-wide kill switch and evidence. Who used what, when. End of debate.
“But That’s a Lot of Identities…” (And Other Predictable Objections)
We have already established one shared CI principal. That is the risk. If that one point of control is compromised, your software stack is coming down like a house of cards. Move to per-run federation and delete static keys from CI. The native tooling is there; the control plane makes the safeguards stick by default. Will you need to do some work to enhance your existing stack? Yes, but not nearly as much work as the impending breach if you don’t.
But an identity per pipeline is too many identities. Smaller units, smaller blast radius. Template roles per repo × env in IaC. Let the control plane handle issuance, TTLs, and revocation so cost and effort doesn’t scale with repo count. Then the trick is how to automate the management at scale. We’ll talk about that.
Our runners are on-prem, and resources in the cloud (or a mix). Your approach can easily bridge trust domains with a little bit of planning. For example, you might use SPIFFE/SPIRE to attest hosts and issue short-lived workload identities; broker that trust into your cloud accounts through the Workload IAM. Uniform policy, everywhere you run.
The Picture in Your Head
Imagine a pipeline handing signed claims to the identity control plane, receiving a just-in-time credential, and assuming a tiny role in one environment to do one job. In parallel, a locked-down signing service — running under its own identity — produces provenance. Build never touches signing keys. Deploy never sees build secrets. Kill one identity, stop one lane.
CI Job ──► Identity Control Plane ──► Cloud Role (scoped, short‑lived) ──► Action
│
└──► Signing Sidecar (dedicated identity)
Your Identity Primitives: How SPIFFE, OIDC, and Workload IAM Fit Together
We’ve been talking about identities as lanes. Here’s how the three pieces keep those lanes narrow and safe — without turning your architecture into a Rube Goldberg machine. OIDC gets your CI runs into cloud roles without storing keys. SPIFFE/SPIRE gives your self-hosted runners and internal services a cryptographically attested identity and mTLS. Workload IAM is the policy brain that decides who gets what, when, and under what conditions — and keeps the receipts.
One picture, two paths
- A) SaaS CI → Cloud (simple)
CI Run ──OIDC claims──► Workload IAM (policy gates, TTL) ──WIF/STS──► Cloud Role (10m)
│
└── audit + revoke
- B) Self-hosted Runner → Internal + Cloud (hybrid)
Runner ──attest via SPIRE──► SVID (SPIFFE) ──mTLS──► Internal services (signer, artifacts)
│
└──► present SVID to Workload IAM ──WIF/STS──► Cloud Role
Why Each Exists (In One Breath)
OIDC is the clean, native way for CI to get per-run cloud access. No stored cloud keys. No shared super-principal.
SPIFFE/SPIRE gives process-level identity and mTLS inside your estate — perfect for self-hosted builders, signers, and artifact movers.
Workload IAM turns both into policy: enforce branch/approvals/signature gates, cap TTLs, narrow scope, broker exchanges, and give security a kill switch with an audit trail. Your Workload IAM should support many forms of identity: OIDC, SPIFFE, cloud metadata, Kerberos, VM vCenter attestation, and more.
When to Reach for What
Use OIDC whenever a SaaS CI needs cloud creds. Add SPIFFE when you run workloads outside SaaS CI or want mTLS by default. Put Workload IAM over both to make the rules reusable and the evidence automatic.
This is the connective tissue between the mental model above and the steps below: The diagram shows how a run becomes a narrow, time-boxed identity; the next section puts that into practice.
Make It Real (Without Blowing Up Your Week)
- Purge static secrets from CI. No long-lived cloud keys in contexts or runner env. Block new “forever” tokens by default.
- Federate CI → cloud with OIDC. Bind trust to repo/branch/workflow claims; issue credentials per run. If you only run a small set of pipelines, federate directly. If you’re operating at scale, simplify by implementing Workload IAM.
- Carve least-privilege roles per environment. Dev ≠ Stage ≠ Prod. Keep actions narrow. Review policy like code.
- Isolate signing and provenance. Separate principal. Short TTL. Store attestations next to artifacts. Govern the signer through Workload IAM.
- Run the containment drill. Revoke one pipeline identity and confirm only that lane stops. This should take minutes, not days.
What “Done” Looks Like
Start your move to identity by isolating each repo per environment. That single move changes your risk profile. For crown jewels, split build vs. deploy and carve identities by protected asset (artifact registry, production database). Encode the pattern in policy so new repos inherit the posture on day one.
No long-lived cloud keys in CI. PAT usage is rare, tightly scoped, short-lived, and gated by Workload IAM. If you don’t yet use Workload IAM, at least gate it by SSO. Every deployment maps to a per-run subject. A break-glass revoke interrupts exactly one lane. And when the security team asks, “Who signed this and from where?” you answer in seconds.
Distinct, ephemeral identities turn CI/CD from a superuser into a narrow, well-lit corridor. A Workload IAM makes the safe path the default, not the exception.
