What is workload identity federation?

How does workload identity federation work?

Every major platform already issues its workloads a native identity token: a Kubernetes cluster projects a service account token into the pod, a CI system mints an OIDC token per job, and each hyperscaler attaches instance identity to its VMs and functions. Workload identity federation makes that native token useful outside its home platform. An administrator registers the external identity provider with the target cloud once, defining which issuer to trust and which token claims, such as repository, branch, namespace, or service account, map to which role.

At runtime the workload presents its platform-issued token to the target cloud's token exchange endpoint, which in some platforms follows the OAuth 2.0 token exchange standard, RFC 8693. The endpoint validates the token against the trusted issuer, checks the claim conditions, and returns short-lived credentials scoped to the mapped role. The workload uses those credentials, they expire within minutes to hours, and nothing persistent was ever written to disk, a pipeline variable, or a secrets store.

What problem does it solve?

Before federation, the standard way to let a workload in one environment call another cloud was to export a long-lived key, a service account JSON file, an access key pair, or a client secret, and paste it into the other side's configuration. Those exported keys are exactly the credentials that end up in repos, CI variables, laptops, and chat threads, feeding secret sprawl: GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024 alone, and found that 70% of secrets leaked in 2022 were still valid years later.

An exported key is also a standing credential. Anyone who copies it can replay it from anywhere until someone notices and revokes it, which is the opposite of zero standing privileges. Federation replaces that standing credential with a proof that must be re-earned on every exchange: the caller has to be the attested workload, running in the attested place, right now. That collapses both the theft window and the rotation burden, because there is no stored artifact to steal or rotate.

Workload identity federation vs static keys

The two approaches answer the same question, how does this workload identity prove itself to an external system, with very different security properties.

• Credential lifetime: federated credentials expire in minutes to hours; static keys often live for years and appear in every NHI lifecycle audit as unrotated.
• Theft surface: federated exchange leaves nothing persistent to exfiltrate; static keys sit in files, environment variables, and vaults waiting to be copied.
• Rotation: federation has no rotation task at all; static keys demand scheduled rotation that teams routinely defer.
• Provisioning: federation is a one-time trust configuration per issuer; static keys are minted per integration and multiply into identity sprawl.
• Auditability: federated credentials carry the caller's attested claims, so logs show which repo, job, or pod acted; a shared static key shows only that someone had the string.

Where is workload identity federation used?

The canonical use case is CI/CD: a pipeline job exchanges its OIDC token for cloud credentials to deploy infrastructure, which removes deploy keys from the CI secret store entirely. The same pattern covers multi-cloud workloads calling across provider boundaries, on-premises services reaching into cloud APIs through a local identity provider, and SaaS platforms that accept customer-side federation instead of asking customers to upload keys.

It is also becoming the preferred way to credential AI systems. An AI agent or model-serving workload that needs cloud data access can run under a federated identity rather than an embedded API key, which keeps high-value credentials out of prompts, tool configurations, and MCP server environments where they are hard to protect.

What are the limits and failure modes?

Federation moves risk from credential storage to trust configuration, and misconfigured trust is its main failure mode. A condition that matches claims too broadly, for example trusting every repository in an organization or omitting a branch restriction, lets any workload under that issuer assume the role. Attackers have abused exactly this in CI ecosystems, so trust conditions deserve the same review rigor as IAM policy, anchored in least privilege.

Federation also does not make credential theft impossible, it makes it time-boxed. The short-lived token a workload holds after the exchange can still be stolen from a compromised process and replayed until it expires. And federation only authenticates the workload; it says nothing about whether what the workload does with its access is normal. Those runtime questions still need runtime visibility into how the federated identity actually behaves.

Frequently asked questions

Related terms