Workload identity federation lets a workload, a cloud service, a CI/CD pipeline, a container, prove its identity to a system in another environment using a pre-established trust relationship instead of a shared secret. It’s the mechanism that lets a GitHub Actions pipeline authenticate directly to AWS, or a workload running in GCP call an API in Azure, without either side ever storing a long-lived credential.
Key Takeaways
- Workload identity federation lets a workload prove its identity to another system using a pre-established trust relationship, not a shared secret.
- It can replace long-lived API keys and service account credentials with temporary credentials scoped to a defined role, resource, or access policy.
- AWS, Google Cloud, and Azure all support federation with external workload identities, commonly using OIDC-based assertions, but each has its own configuration model and trust semantics.
- It’s not the same as a secrets manager: a secrets manager centralizes storage but still distributes a persistent secret, while federation means the workload never handles one at all.
- Scaling federation across many services and clouds, not setting it up for one connection, is the hard part; that’s the gap platforms like Aembit are built to close.
As infrastructure becomes more automated, the real identity fragmentation sits between workloads: CI/CD pipelines authenticating to SaaS tools, containers accessing APIs, and jobs calling into services across clouds.
Each environment has its own identity system, and none of them talk to each other out of the box. So teams patch together secret vaults, duplicate identities, or accept over-permissioned access just to get things working. The result is secrets sprawl, audit headaches, and brittle configurations that break whenever someone rotates a credential or changes a deployment target.
Identity federation offers a different model. Instead of duplicating accounts or sharing credentials, one identity system can validate identities issued by another and grant access based on that trust. For non-human identities, this means a workload running in one cloud can prove who it is to a service in another cloud without either side storing a shared secret. The capability already exists in every major cloud platform and can be implemented with native tools and open standards, as our identity federation use case walks through. The challenge is making it work consistently across environments at scale.
Why Human Federation Models Break Down for Workloads
Workforce federation commonly assumes an interactive user session, while workloads need non-interactive authentication. The same browser-driven login pattern does not map directly to machine-to-machine access, even though standards such as OIDC can still play an important role in workload federation.
In the workforce context, SAML, OIDC, and SSO make it straightforward for users to authenticate across tools without managing separate accounts: a user logs in through an identity provider, which brokers identity to downstream applications, using browser redirects, login screens, and session tokens.
Workloads operate differently. They don’t open browsers, click login buttons, or respond to MFA prompts. They’re automated, often ephemeral, and distributed across environments. A Kubernetes pod that lives for 30 seconds can’t go through an interactive authentication flow. Neither can a serverless function processing a batch job or an AI agent chaining API calls across three cloud providers.
The workaround most teams reach for is long-lived keys. A developer provisions a static API key, stores it in a vault or environment variable, and moves on. That key works indefinitely, for anyone who has it, with whatever permissions were granted on day one. It’s the path of least resistance, and it’s also the access pattern behind most nonhuman identity breaches. Unrotated credentials enabled the Snowflake customer breaches. A stored service account credential started the 2023 Okta incident. GitGuardian’s 2026 report found roughly 29 million secrets detected on public GitHub in 2025, a 34 percent year-over-year increase.
The pattern persists because the alternative has historically been harder than the risk. Configuring federation between two environments requires understanding both identity systems, mapping token claims to IAM policies, and testing the flow end to end. Multiply that by every service-to-service connection in your environment and you can see why teams default to static keys.
Federation for workloads addresses this by enabling identity assertions at runtime. Instead of presenting a long-lived shared secret, the workload presents a signed identity assertion, often an OIDC-compatible JWT, that the receiving system can validate against a pre-established trust relationship.
How Workload Federation Works at Runtime
Workload federation happens in two phases: a one-time trust setup between your identity provider and each target cloud, followed by dynamic, per-request authentication that needs no human involvement.
Trust configuration is a one-time setup. Google Cloud uses Workload Identity Pools and Providers linked to your external OIDC issuer. AWS requires registering an IAM Identity Provider and defining a trust policy on an IAM role. For Azure, you register the external identity provider through Entra ID and associate it with a service principal. Each platform has its own configuration model, but all of them accept OIDC tokens and exchange them for short-lived, scoped credentials.
Once trust is in place, the workload obtains identity evidence from its native environment. A GitHub Actions workflow, for example, can obtain an OIDC token, while other platforms use their own workload identity mechanisms. An AWS EC2 instance uses its metadata service. An Azure workload uses a managed identity or OAuth token flow. That token contains verifiable claims describing the workload’s identity: repository path, cloud role, namespace, object ID.
The workload then presents that token to the target cloud’s Security Token Service. If the identity and claims match the configured trust policies, the cloud returns temporary tokens scoped to the requested resource. The workload uses those tokens to access the resource, and they expire automatically, typically within minutes to a few hours. Token exchanges and API activity can be logged with identity and request context.
This model eliminates the need to provision and rotate static secrets or maintain long-lived identities in every environment. Workloads operate with ephemeral access based on verified identity assertions. No credentials are stored in code, pipeline configurations, or environment variables. Unlike a secrets manager, which centralizes storage but still requires distributing the secret to the workload, federation means the workload never handles a persistent credential at all. The identity is the access method.
Common Workload Federation Patterns
Workload identity federation shows up in three recurring patterns across most environments: CI/CD-to-cloud, cross-cloud service-to-service, and Kubernetes-to-cloud-API access.
CI/CD to cloud: A GitHub Actions or GitLab CI pipeline needs to deploy to AWS, push a container to a registry, or pull a secret from a vault. Instead of storing a long-lived AWS access key as a pipeline secret, the pipeline presents its OIDC token and receives short-lived, scoped AWS credentials for that run only.
Cross-cloud service-to-service: A workload running in GCP needs to call an API hosted in AWS or Azure. Rather than provisioning and syncing a separate credential in each cloud, the workload federates its GCP identity into the target cloud’s trust model and receives a scoped credential for that specific call.
Kubernetes to cloud API: A pod needs to read from an S3 bucket or write to a GCS bucket. Its Kubernetes service account token is exchanged, via the cluster’s OIDC issuer, for temporary cloud credentials scoped to that pod’s role, with no static key stored in the cluster.
Workload Identity Federation vs. a Secrets Manager
A secrets manager and workload identity federation solve adjacent but different problems: one centralizes and distributes secrets more safely, the other removes the need to distribute a secret at all.
A secrets manager, such as HashiCorp Vault or AWS Secrets Manager, is a real improvement over secrets scattered across config files and environment variables. It gives you a single place to store, rotate, and audit credentials. But the workload still has to retrieve that secret at some point, which means it still exists somewhere a workload, or an attacker who compromises that workload, can read it.
Federation removes that step. Instead of retrieving a stored secret, the workload presents a cryptographically verifiable identity assertion, and the receiving system issues a short-lived credential on the spot. There’s no persistent secret to leak, because none is ever stored or retrieved in the first place. In practice, many organizations run both: a secrets manager for credentials that genuinely can’t be federated yet (some databases, legacy systems, certain SaaS tools), and federation for everything that can be.
What Federation Replaces
Federation replaces the workarounds teams reach for when systems can’t verify each other’s identities directly: shared static secrets, duplicated accounts, and over-permissioned service credentials that create compounding risk as they spread.
That risk compounds in predictable ways. Secrets spread across tools and teams with no single source of truth. Revoking access becomes error-prone because nobody knows everywhere a key was copied. Rotation procedures break down as secrets multiply. Incident response slows because the blast radius of a compromised credential is unclear. Audit trails fragment across environments.
If you’ve ever had to track down every place a leaked API key was used, you know how painful this gets. The key might be in a CI/CD pipeline, an environment variable on three different compute instances, a Terraform state file, and a developer’s local configuration. Revoking it means finding all of those locations, and missing even one leaves the door open.
Federation sidesteps these problems by shifting the trust model. Instead of copying a secret to every place access is needed, each workload presents a verifiable identity that’s recognized across boundaries. You don’t need to inject or sync secrets across environments. Credentials are issued just in time and scoped to the specific request. Policy is enforced dynamically based on verified identity and context.
For your developers, this means less time managing authentication plumbing and more time building features. For your security team, it means centralized visibility into what’s accessing what, with credentials that can’t be stolen from a repository or leaked in a log file. For compliance, it means every access event is traceable to a verified identity with a defined policy, not to a shared key that three teams have access to.
The gap between what federation handles natively and what most organizations need at scale is real, though. Each cloud has its own federation mechanism, its own token format, and its own trust semantics. AWS uses IAM roles and web identity federation, GCP has workload identity pools, and Azure uses service principals through Entra ID. Some systems expect SAML, others OIDC, others proprietary token formats. Scaling federation means configuring trust relationships for every combination of source and target environment, and every application needs to handle identity flows, manage token exchanges, and integrate with the federation control plane. Without the right abstractions, this complexity slows teams down and increases the risk of misconfiguration.
Getting Started with Workload Identity Federation
Rolling out workload identity federation is a four-step process: inventory your static credentials, prioritize your highest-risk connections, configure native federation per cloud, and then decide how you’ll manage it once it’s live across more than a handful of services.
- Inventory where long-lived credentials currently live: CI/CD secrets, environment variables, Terraform state, hardcoded config.
- Prioritize the connections with the highest blast radius if leaked: typically CI/CD-to-production-cloud access and cross-cloud service calls.
- Configure native OIDC federation for each target cloud: Workload Identity Federation in GCP, an OIDC identity provider and trust policy in AWS, workload identity federation through Entra ID in Azure.
- Decide how you’ll manage federation at scale: past a handful of services, a federation hub can be the difference between a proof of concept and something a lean team can actually operate day to day. This property management firm’s experience moving off secrets managers across a multi-cloud environment is a useful reference point for what that looks like in practice.
From Native Federation to Managed Access
Cloud-native federation gives you the right trust model, but making it practical across every service, team, and cloud, without turning every engineer into an identity expert, is the operational challenge it doesn’t solve on its own.
Aembit builds on the federation foundation by acting as a federation hub across trust boundaries. You configure federation once per environment, and Aembit handles the runtime token exchange, policy enforcement, and credential issuance for every workload that needs access. This removes the pairwise federation problem where each service-to-service connection requires its own trust configuration. It also removes the developer burden: Aembit’s Edge component intercepts workload requests and injects tokens transparently, so applications don’t need custom authentication code.
On top of federation, Aembit layers conditional access based on workload identity and posture. If a workload fails a CrowdStrike or Wiz vulnerability check, access is blocked regardless of whether the identity token is valid. Every access event and policy decision is logged centrally. Your security and compliance teams get a single audit trail across clouds, SaaS, and on-premises environments.
If you’re moving away from long-lived secrets or trying to make sense of workload access across clouds, federation is the right foundation. It shifts the trust model from “who has the secret” to “can this workload prove who it is.” Aembit’s workload IAM platform helps make it practical.
Related Reading
FAQs
How is workload identity federation different from human/user identity federation?
Human federation (SAML/OIDC SSO) assumes an interactive session, a person can click through a login screen and respond to an MFA prompt. Workloads can’t do either. Workload identity federation instead relies on non-interactive, cryptographic attestation, like a signed OIDC token from a CI/CD platform or cloud metadata service, that a workload can present automatically.
Does workload identity federation replace a secrets manager?
Not entirely. It removes the need to store and retrieve a secret for anything that can be federated, which covers most cloud-to-cloud and CI/CD-to-cloud access. But some systems, like databases without certificate-based auth or legacy on-prem applications, still can’t participate in federation and need a secrets manager for those specific credentials.
Which clouds support workload identity federation natively?
AWS, Google Cloud, and Azure all support it, each with its own model: AWS uses IAM Identity Providers and web identity federation, GCP uses Workload Identity Pools and Providers, and Azure uses workload identity federation through Entra ID. All three accept OIDC tokens and exchange them for short-lived, scoped credentials.
Is workload identity federation the same thing as OIDC?
No.OIDC is an identity protocol commonly used in workload federation; the identity assertions are often JWTs. Federation is the broader trust relationship and exchange process; OIDC is just the most common mechanism used to carry it out.
Do I need Kubernetes to use workload identity federation?
No. Kubernetes workloads are one common case, via service account token exchange, but CI/CD pipelines, serverless functions, and VM-based workloads can all federate their identity using the OIDC or platform-native attestation methods available to them.
Does adopting a federation hub like Aembit mean replacing my cloud-native federation setup?
No. Aembit builds on the native federation each cloud already provides rather than replacing it. You configure the trust relationship once per environment, and Aembit handles the runtime token exchange and policy enforcement across all the workloads that need it.
The Workload IAM Company
Manage Access, Not Secrets
Boost Productivity, Slash DevSecOps Time
No-Code, Centralized Access Management
