Workload identity & keyless auth
A long-lived cloud access key is a loaded gun lying on a table. It works forever, from anywhere, for anyone who picks it up — and the entire industry's worst credential leaks are exactly this: a permanent key copied into a Git repo, a CI config, a laptop. The modern answer is radical and simple: stop having keys at all. Instead of handing a machine a permanent secret, the machine proves who it is and receives a short-lived credential that expires in minutes. This lesson is how that magic works — for your running workloads and for your CI/CD pipelines — and why it's the highest-leverage security upgrade most teams can make.
On-ramp in one breath: don't store a permanent key your CI job or app could leak. Let the job prove its identity to the cloud and get a credential that's gone in minutes — nothing durable to steal.
The problem with long-lived static keys
Chapter 2 told you to give machines roles, not keys, and explained that the platform hands a running VM/container short-lived credentials automatically. That works beautifully inside one cloud. But two gaps remain, and they're where leaks happen:
- Cross-boundary access. Your CI pipeline runs on GitHub Actions (or GitLab, etc.), outside your cloud. To deploy, it needs cloud permissions. The lazy fix is to paste a long-lived cloud access key into the CI secrets. That key now lives in a system outside your cloud, in plaintext to anyone who can edit the pipeline, and it never expires.
- Static keys in apps. A developer copies a key into an app's config "just to get it working," and it ships to prod and into Git history forever.
A long-lived static key is, by definition: durable (works for months/years), portable (works from anywhere), and bearer (whoever holds it is it). Those three properties are exactly what makes a leaked one catastrophic.
The core idea: federation via OIDC
The fix is federation: instead of the cloud storing a separate password for your CI system, the cloud is configured to trust an external identity provider and accept the token that provider already issues. The standard token format is OIDC — OpenID Connect, a widely-used identity protocol — and the token is a short-lived, cryptographically-signed JWT (JSON Web Token, a signed JSON blob asserting "I am this workload").
Here's the keyless dance for a CI pipeline deploying to your cloud:
Trace it: the CI job never holds a permanent cloud secret. It asks its own provider for a fresh signed token that says "I am the deploy job for repo X on branch main." The cloud was pre-configured to trust that provider and to allow that specific token (right repo, right branch) to assume a specific role. It hands back credentials that expire in minutes. Nothing durable to leak exists. If an attacker steals the token, it's already expiring and scoped to that one workload.
:::tip The durable rule Prefer keyless federation over any long-lived key. If a system needs cloud access, ask: can it present an OIDC token I can trust instead of holding a static secret? For CI/CD, the answer in 2026 is almost always yes — and it eliminates the single most common source of cloud credential leaks. The protocol (OIDC) is durable; the per-provider setup is dated. :::
Workload identity inside Kubernetes: IRSA / Workload Identity
The same federation idea solves a Kubernetes-specific problem. A pod needs cloud permissions (to read a bucket, say). The old, bad way: bake a cloud key into the pod's Secret. The keyless way ties the pod's Kubernetes service account (its in-cluster identity, Ch. 4) to a cloud role via OIDC:
- On AWS EKS this is IRSA — IAM Roles for Service Accounts.
- On GCP/Azure the same pattern is called Workload Identity (and Workload Identity Federation).
The cluster is registered as an OIDC provider the cloud trusts. A pod's service-account token is exchanged for short-lived cloud credentials scoped to exactly one role. Result: a pod gets precisely the cloud permissions it needs, with no key stored anywhere, credentials auto-rotated. It's least privilege (8.2) plus keyless auth, fused.
Short-lived credentials everywhere
The unifying principle behind all of this is short-lived credentials: a credential that expires automatically, soon. Compare the two worlds for a leaked credential:
| Long-lived static key | Short-lived credential | |
|---|---|---|
| Lifetime if leaked | Months/years — until you notice and rotate | Minutes — self-expires |
| Where it lives | Stored in CI/config/Git, copied around | Issued on demand, never stored |
| Blast radius window | Huge | A sliver |
| Rotation effort | Manual, forgotten | Automatic, built in |
A leaked long-lived key is an open-ended emergency; a leaked short-lived credential is often already useless by the time anyone has it. This is why "make credentials short-lived" is one of the most cost-effective security wins in the cloud — and it mirrors the just-in-time access idea from 8.2 (short in time shrinks the target).
Why it matters
Long-lived static keys are durable, portable, bearer secrets — exactly the properties that make a leak catastrophic, and they're the #1 source of cloud credential breaches. Keyless auth removes the secret entirely: a workload (a CI job, a pod) proves its identity via a short-lived signed OIDC token, the cloud trusts that provider via federation, and hands back short-lived credentials scoped to one role. For pipelines, configure OIDC federation instead of pasting a key; for Kubernetes, bind service accounts to cloud roles via IRSA / Workload Identity. The credentials expire in minutes, auto-rotate, and leave nothing durable to steal. If you change one thing after this chapter, make it this.
Common pitfalls
- Pasting a long-lived cloud key into CI secrets. The classic leak. Replace it with OIDC federation — supported by the major CI systems and clouds in 2026.
- "Temporary" keys that are actually permanent. A key you generated by hand and "plan to rotate" is long-lived. Only auto-expiring, issued-on-demand credentials count as short-lived.
- Over-broad trust policies. Federation is only as safe as its claim checks. "Trust any token from this provider" is too loose — scope it to the specific repo/branch/service account, or anyone on that provider can assume your role.
- Baking cloud keys into pod Secrets. Use IRSA / Workload Identity so the pod gets keyless, short-lived, least-privilege credentials instead.
Where this connects
- Back to Chapter 2 · IAM and 8.2 — keyless auth is least privilege applied to machines with zero stored secret.
- Back to Chapter 4 · Config & secrets — the best secret is the one that doesn't exist; keyless removes whole classes of stored secrets.
- Forward to 8.4 Secrets & encryption — for the secrets you genuinely must store, here's how to do it safely.