Long-lived access keys are the root cause behind most cloud breaches. This is the complete map to keyless auth — how workload identity federation and OIDC replace static secrets everywhere, and where to start.
Keyless Cloud Authentication — Ending Static Credentials Across AWS, GCP, and Azure
Almost every large cloud breach of the last few years traces back to the same root cause: a long-lived credential that leaked. An access key committed to a public repo. A service account JSON pasted into a CI variable that got logged. A personal access token in a Slack message. Static secrets are the single largest attack surface most teams carry, and the fix is now mature enough to adopt everywhere: stop issuing long-lived credentials at all.
This is the map. Keyless authentication replaces stored secrets with short-lived tokens that a trusted identity provider mints on demand, based on who or what is asking rather than what secret they hold. It has a name in each ecosystem — workload identity federation, OIDC federation, IAM Roles Anywhere, projected service account tokens — but the mechanics are the same everywhere. This guide ties the whole cluster together and points you to the deep dive for each piece.
A static credential has three properties that make it dangerous: it's long-lived (often never rotated), it's bearer (whoever holds it is trusted), and it's copyable (it exists in more than one place the moment you use it). Put those together and a single leak is a standing invitation that may not be noticed for months.
The usual mitigations — rotation schedules, secret scanners, vaulting — reduce the blast radius but don't remove the fundamental issue. If you never have to know how to detect and rotate a leaked cloud credential, it's because you stopped minting credentials that can leak. That's the goal.
Keyless auth works by establishing trust between identity systems instead of sharing a secret. A workload proves its identity to its own platform (GitHub, Kubernetes, an EC2 instance), receives a signed OIDC token asserting that identity, and exchanges that token with the target cloud for short-lived credentials scoped to a specific role.
The exchange has four moving parts everywhere:
- An identity provider (IdP) that issues signed tokens — GitHub Actions, a Kubernetes API server, Google, Entra ID.
- A trust relationship configured on the target: "I trust tokens from this issuer, for these subjects."
- A token — a short-lived JWT with claims (
sub, aud, iss) describing the workload.
- A role/permission set the token is allowed to assume, following least privilege.
No secret is stored anywhere. The token lives for minutes and is scoped to one workload. If it leaks, it's already expired.
Each provider implements the same pattern with different names and a slightly different trust config.
AWS uses OIDC federation and, for on-prem/other-cloud workloads, IAM Roles Anywhere. If your workloads run outside AWS, IAM Roles Anywhere issues temporary credentials against an X.509 trust anchor. For CI and federated identities, you configure an OIDC provider and a role trust policy — the same mechanism behind OIDC federation from GitHub Actions to AWS.
GCP calls it Workload Identity Federation, and it's the highest-traffic topic on this site for a reason: it cleanly replaces the service-account-key files that used to sprawl across every pipeline. The full walk-through lives in GCP Workload Identity Federation: replacing service account keys.
Azure federates through Entra ID. The setup mirrors the others — register a federated credential on a managed identity or app registration, pointed at your IdP's issuer — and is covered in Azure Workload Identity Federation without secrets.
When you operate across more than one provider, the trust topology gets its own design considerations — see cross-cloud identity federation patterns.
CI is where static keys do the most damage, because pipelines run untrusted code and log verbosely. Every major CI platform can now present an OIDC token instead of holding a cloud secret. GitHub Actions is the common case, but the same approach extends to GitLab, Buildkite, and generic providers — covered in OIDC federation beyond GitHub. The payoff: your pipeline holds zero cloud credentials, and access is scoped per-repo, per-branch, or per-environment via token claims.
Workloads in a cluster shouldn't carry mounted secrets to talk to cloud APIs either. Kubernetes issues projected service account tokens — short-lived, audience-scoped OIDC tokens — that federate directly to AWS/GCP/Azure IAM. For service-to-service auth within the mesh, identity is carried by SPIFFE and SPIRE or by mutual TLS rather than shared API keys.
Not everything federates. Database passwords, third-party API keys, and legacy systems still need a secret somewhere. The goal there is to make those secrets short-lived and centrally brokered rather than static and scattered. That's the job of a secrets manager: HashiCorp Vault issues dynamic, time-boxed credentials; on Kubernetes you either run Vault as the secrets backend or sync from a cloud secrets manager with the External Secrets Operator. The underlying principle — short-lived credentials via STS and dynamic secrets — is what makes even the non-federated cases safe.
You don't rip out static keys in one weekend. This is the order that works:
- Inventory. Find every long-lived credential — access keys, service account JSON, PATs, CI secrets. Secret scanners and cloud credential reports surface most of them.
- Start with CI. It's the highest-risk, lowest-effort win. Convert one pipeline to OIDC, confirm it works, then template it across repos.
- Federate workloads next. Move in-cluster and cross-cloud workloads to projected tokens / workload identity federation.
- Broker the rest. Route remaining static secrets through Vault or a cloud secrets manager with short TTLs, and adopt the zero-trust posture of never trusting a network location as a proxy for identity — including on AWS with IAM Identity Center.
- Delete the old keys and alarm on their return. Once a workload is federated, revoke its old credential and add detection so a new static key is treated as an incident.
Adopt keyless everywhere it's supported, and treat the remaining static secrets as debt to broker down to short TTLs. The trust configuration takes an afternoon per provider; the payoff is that your worst-case credential leak becomes a token that expired before anyone could use it. Start with CI/CD this week — it's the fastest path from "our secrets are everywhere" to "we don't have secrets to leak." Each linked guide above is a concrete step; work them in the migration order and the static-credential attack surface shrinks to nearly nothing.
