Abstract
Static long-lived credentials - service account keys distributed as environment variables or stored in secret managers - have been the default approach for authenticating workloads to cloud APIs for over a decade. Workload identity federation replaces these credentials with short-lived tokens obtained by exchanging a workload’s native identity proof (a Kubernetes service account token, a GitHub Actions OIDC token, or an AWS instance identity document) for a cloud provider credential, without any static secret leaving the issuer. Implementing federation consistently across AWS, GCP, and Azure is operationally achievable and eliminates an entire class of credential-theft attack that continues to be a leading cause of cloud breaches.
The Credential-Theft Problem in Multi-Cloud Workloads
Long-lived service account keys are difficult to rotate, easy to exfiltrate, and frequently committed to source repositories or left in container images. The 2024 Datadog State of Cloud Security report noted that over 60 percent of GCP organizations had at least one service account key downloadable by a principal outside the intended scope. When a key is stolen - through a repository leak, a compromised CI artifact, or a container escape - the attacker obtains persistent access without needing to maintain a foothold on the originating host.
Workload identity federation eliminates the static key entirely. Instead, a workload presents a short-lived identity assertion signed by a trusted issuer, and the cloud provider’s Security Token Service (STS) validates that assertion and returns a time-bounded credential scoped to the configured permissions.
Federation Mechanics on Each Major Provider
On Google Cloud, Workload Identity Federation is configured through Workforce Identity Pools. A Kubernetes workload running outside GKE can present its projected service account token (a standard OIDC JWT) to the GCP STS endpoint. The pool validates the token against the OIDC discovery endpoint of the Kubernetes cluster, then returns a short-lived access token. The google-auth library’s IdentityPoolCredentials class handles this exchange transparently.
AWS IAM roles support Web Identity federation natively via sts:AssumeRoleWithWebIdentity. GitHub Actions, for example, requests an OIDC token from GitHub’s issuer (token.actions.githubusercontent.com), then calls STS with that token to assume a role whose trust policy requires the token’s sub claim to match a specific repository and branch pattern. This prevents workflows in forked repositories from assuming production roles.
Azure’s Federated Identity Credentials (FIC), available on Managed Identities and App Registrations, follow the same pattern: a federated credential is configured with the external issuer URL and subject claim, and client libraries exchange the external token for an Azure access token through the Azure AD STS.
Cross-Cloud Token Exchange and SPIFFE Integration
In environments where workloads run across cloud boundaries - a job running on GKE that must write to an S3 bucket, for example - token chain exchange is necessary. The workload obtains a GCP access token from the GKE metadata server, exchanges it at the AWS STS endpoint via an AssumeRoleWithWebIdentity call, and uses the resulting AWS credential. SPIFFE (Secure Production Identity Framework for Everyone) and its runtime implementation SPIRE provide a cloud-agnostic identity layer: every workload receives a SPIFFE Verifiable Identity Document (SVID) regardless of where it runs, and SVIDs can be exchanged for cloud-specific credentials through SPIRE’s AWS, GCP, and Azure plugins. This architecture is particularly useful in environments where the cloud provider changes but the identity issuance model should remain consistent.
Migration Strategy for Teams with Existing Key-Based Auth
Migration from static keys to federation should proceed incrementally. Begin with CI/CD pipelines - GitHub Actions, GitLab CI, and CircleCI all have native OIDC token support - as these are often the easiest to migrate and carry the highest risk due to broad permissions and wide contributor access. Move next to non-production workloads where the blast radius of misconfiguration is lower. For Kubernetes workloads, enabling projected service account token volumes (available by default in Kubernetes 1.21 and later) and configuring the cloud provider’s workload identity binding per service account is the standard path. Complete audits using each provider’s access advisor tooling to confirm that no remaining principals hold downloadable keys after migration.