Workload Identity Federation: How Cloud Services Authenticate Without Static Secrets

Workload identity federation lets software exchange an identity proof from its environment for a short-lived cloud credential. It removes the need to store a target service account key, access key, or client secret. Trust moves into issuer configuration, token claims, and access policy.

The cloud still has to identify the workload precisely through issuer, subject, audience, claim mapping, and target role. A short expiry limits a stolen token, but it does not correct a policy that accepts the wrong subject.

A workload identity identifies a process, service, job, or application rather than a person. It is one type of non-human identity, with a lifecycle tied to software and its execution environment.

Key Takeaways

• Workload identity federation exchanges a local subject token or assertion for a target credential instead of distributing a static cloud secret.
• Issuer, subject, audience, and attribute conditions decide which workload can assume a role or receive access.
• AWS, Google Cloud, and Microsoft Entra use related federation patterns, but their trust objects and authorization paths are different.
• Short-lived credentials reduce exposure time, while revocation, token audience, key rotation, and narrow policy still need explicit controls.

How Workload Identity Federation Authenticates a Service

The workload begins with a credential issued in its current environment. It may be an OIDC token, a SAML assertion, an AWS signed request, or an X.509 certificate. The receiving cloud validates it against configured trust.

If validation succeeds, a Security Token Service or authorization server issues a target credential with its own permissions and expiry. Later API calls use an assumed role, service account, managed identity, or federated principal.

NIST SP 800-207A describes cloud-native access policy through application and service identities rather than network location alone. Federation authenticates such identities across boundaries, while the target service retains authorization.

A valid token format is not enough. The receiving system must trust the issuer, verify its signature, accept the intended audience, and map the subject under current policy. Failure at any one check should stop the exchange.

Subject Tokens and STS Exchanges Carry the Identity

RFC 8693 defines OAuth 2.0 token exchange and an HTTP and JSON Security Token Service model. A request includes a subject_token and token type, with optional audience, resource, scope, or actor data.

The subject token identifies the party behind the request. It often contains an issuer (iss), subject (sub), audience (aud), and expiry. The server validates the token and policy before issuing another credential.

OIDC provides issuer discovery, signing keys, and JWT claims. SAML can serve the same purpose through signed XML assertions. Google Cloud supports both, while the AWS and Microsoft patterns below use OIDC tokens.

RFC 8693 notes that exchange does not invalidate the subject token and that revocation propagation is implementation specific. Deleting trust can stop new exchanges without cancelling every credential already issued.

Kubernetes Service Accounts Provide Bound Subject Tokens

Kubernetes assigns a ServiceAccount through spec.serviceAccountName. Its ServiceAccount documentation recommends the TokenRequest API or projected volumes for short-lived, rotating tokens. Long-lived token Secrets are no longer recommended.

A projected token is a signed JWT that identifies the namespace and ServiceAccount. It can be bound to a pod and requested for a specific audience. The application must read rotations rather than cache the first token.

Token audience limits where the credential is accepted

The receiver needs to check audience so a cloud STS token does not work at an unrelated service. Kubernetes recommends defining and verifying accepted audiences.

TokenReview can reject a bound token after its pod or ServiceAccount disappears. Offline OIDC validation may accept that JWT until expiry, which makes lifetime and audience important.

Reusing the default ServiceAccount across unrelated workloads makes the subject too broad for least privilege. Separate namespaces do not help if external policy ignores the namespace in sub.

AWS, Google Cloud, and Microsoft Entra Map Trust Differently

Each cloud validates an external identity and issues temporary access through its own trust objects. A migration must preserve the decision rather than copy field names.

AWS maps OIDC claims into an IAM role trust policy

AWS Security Token Service provides AssumeRoleWithWebIdentity. The caller presents an OIDC token, and AWS returns temporary credentials for an IAM role. The role trust policy can restrict audience and subject.

Amazon EKS role federation uses the cluster OIDC issuer and a projected token. AWS’s EKS guide shows aud set to sts.amazonaws.com and sub set to a namespace and ServiceAccount. The role policy limits later AWS access.

Without a narrow subject condition, extra ServiceAccounts may assume the role. Node credentials also create a fallback if pods retain instance metadata access.

Google Cloud maps external claims into pool attributes

Google Cloud Workload Identity Federation uses pools for external identities. A provider maps issuer claims into google.subject, groups, or custom attributes before STS returns a federated token.

The principal can access a supported resource directly or impersonate a service account. These paths create different policy and audit relationships, even though both provide short-lived access.

Google’s federation guidance recommends immutable attributes and tenant conditions for shared issuers such as GitHub. Issuer validation alone does not identify an organization or repository.

Microsoft Entra matches a federated identity credential

A Microsoft Entra federated identity credential links an external issuer to an application or managed identity. Entra checks issuer, subject, and audience before exchanging the token without an application secret.

On AKS, Microsoft Entra Workload ID uses a projected ServiceAccount token and the cluster OIDC issuer. Azure Identity or MSAL requests the Entra credential for the mapped namespace and ServiceAccount.

Microsoft’s federated credential configuration does not support wildcards in these fields. Case or value differences in issuer, subject, or audience cause exchange failure, so test the full flow after configuration.

SPIFFE and SPIRE Establish Workload Trust Domains

Cloud federation grants provider access, while SPIFFE addresses identity across heterogeneous systems. A SPIFFE ID such as spiffe://example.org/payments/api combines a trust domain with a workload path.

The SPIFFE concepts define a trust domain as an identity namespace tied to a root. A workload proves its ID with a short-lived X.509-SVID or JWT-SVID, verified through a trust bundle.

A trust domain is a security boundary, not a naming convenience. Environments with different administrators or security controls may need separate domains, even when their services share a company DNS name.

SPIRE attests nodes and workloads before issuing SVIDs. The SPIFFE Workload API streams credentials and updated bundles to an authorized local process, which supports automatic rotation.

SPIFFE federation distributes bundles so domains can validate each other’s SVIDs. A separate bridge or cloud configuration can exchange a workload proof for a provider credential.

Trust Policy Mapping Determines the Effective Identity

Federation policy maps an external identity into a target principal. Bind a trusted issuer to an immutable subject, expected audience, environment, and role. Use extra attributes only when the issuer controls them reliably.

Issuer, subject, and audience work together. A shared issuer may represent many organizations, while a reused subject can collide across domains. Audience checks restrict the intended receiver.

Authorization begins after mapping, so the target role or principal still needs narrow permissions. Federation removes a static credential but does not make a broad role safe.

Record each issuer, accepted claim, mapped principal, policy, lifetime, and owner. Test an allowed workload plus nearby subjects that must fail.

Rotation and Revocation Need Separate Plans

Short-lived credentials replace manual secret rotation with repeated issuance. Provider libraries must refresh before expiry and handle temporary STS or discovery failures.

Signing-key rotation needs overlap and current discovery data. A validator with a stale key set can reject new tokens, while removing an old key too early can break tokens that have not expired.

Revocation is less immediate. Removing trust prevents new exchanges, but an issued token or role session may remain valid until expiry. RFC 8693 does not define automatic revocation propagation.

SPIFFE can stream updated SVIDs and bundles. Kubernetes TokenReview can invalidate a bound token after its object disappears, while offline OIDC consumers may accept it until expiry.

Emergency response covers both sides: disable the source or issuer trust, remove target mapping, revoke sessions where supported, and inspect the mapped principal. A short lifetime limits residual access but does not complete the response.

Common Federation Failures Come from Trust and Fallback Paths

The most serious failures accept too many subjects, such as every repository under a shared issuer or every ServiceAccount in a namespace. The token remains valid even though policy assigns the wrong identity.

A missing audience check can permit reuse, while an incorrect value causes a valid exchange to fail. Issuer URLs and subject strings may also require exact, case-sensitive values.

Static fallback credentials can hide broken federation. Remove old environment keys, node access, and developer credentials during tests, then confirm the principal in audit logs.

Cached tokens, stale trust bundles, clock drift, unavailable discovery, and failed refresh also break authentication. Monitoring should separate source acquisition, STS exchange, authorization, and refresh errors.

Frequently Asked Questions

What is workload identity federation?

Workload identity federation uses an identity from one environment to obtain access in another. A target STS validates it and issues a short-lived credential under policy. This replaces a stored target key for supported paths.

Is workload identity federation the same as OIDC?

No, OIDC is one way to issue and validate a subject token. Systems may also accept SAML, X.509 certificates, signed cloud credentials, or SPIFFE documents. Target authorization remains separate from the source protocol.

How do Kubernetes ServiceAccounts authenticate to cloud APIs?

Kubernetes projects a short-lived ServiceAccount token into the pod for a defined audience. The cloud validates its issuer and maps the subject to a target identity. A provider library exchanges and refreshes the cloud credential.

Can short-lived credentials be revoked immediately?

Expiry limits credential lifetime, but revocation depends on the issuer, validator, and provider. Removing trust usually blocks new exchanges while active sessions may survive until expiry. Incident plans need to address both source and target access.

Workload Federation Replaces Secrets with Verifiable Trust

Workload federation removes a static target credential, not credential management. Issuers, keys, tokens, trust policies, and authorization still need visible lifetimes and owners.

A sound design uses stable identity, restricted audience, immutable claims, and narrow permissions. It tests rejection paths and plans for expiry and revocation, tying access to a workload rather than a copied secret.