What is workload identity federation?

Workload identity federation is a way for software running outside a cloud, such as a CI job, a server in another cloud or an on-premises service, to get short-lived access to that cloud by presenting an identity token from a system the cloud has been told to trust, instead of a long-lived key stored with the software.

The problem it removes

The traditional way to let a pipeline deploy to Google Cloud or AWS is a key: a service account key file or an IAM access key, saved in CI settings. Google is direct about the cost: "service account keys are powerful credentials, and can present a security risk if they are not managed correctly", and federation "eliminates the maintenance and security burden associated with service account keys" (Google Cloud). A stored key works from anywhere, for as long as nobody revokes it, and every copy is as good as the original.

How it works

The names differ by cloud. The shape is the same:

1. Trust is configured once. You tell the cloud which external issuer to accept, such as GitHub Actions, GitLab or another OIDC provider, and which claims in its tokens must match. Google calls the container for this a workload identity pool, with a provider describing "a relationship between Google Cloud and your IdP". AWS uses an IAM OIDC identity provider and a role trust policy.
2. The workload gets a token from its own platform. A CI job asks its provider for a signed JWT that names the repository, branch and environment.
3. The token is exchanged. The workload sends it to the cloud's token service. Google's flow "follows the OAuth 2.0 token exchange specification" and ends with "a short-lived OAuth 2.0 access token". AWS returns temporary credentials from AssumeRoleWithWebIdentity.
4. Access expires on its own. Nothing reusable is left behind.

id_tokens:  ID_TOKEN:    aud: https://iam.googleapis.com/projects/…/providers/kiteline-ci

Common mistakes

• Trusting the issuer, not the workload. Every customer of a hosted CI service gets tokens from the same issuer. A rule that checks only the issuer accepts all of them. Pin the repository or project, and for production the branch or environment. See OIDC subject claim.
• One identity for every job. A test job and a production deploy with the same role have the same power.
• Keeping the old key "for emergencies". The stored key is the thing federation was meant to remove.
• Assuming the token is harmless. Until it expires, it is a credential. Don't print it in logs.

Federation for secrets that aren't cloud keys

Federation gets a job into a cloud's own APIs. Many pipelines also need values no cloud issues, such as a payment provider's test key or a database URL. You can keep those in the cloud's secret manager and read them after federating, or use a vault that accepts the CI provider's token directly.

Crunu does the second. A Crunu service token can carry a CI binding (OIDC): rules for GitHub Actions, GitLab CI, Bitbucket Pipelines or any OIDC issuer that pin the repository, branch or deployment environment. With a binding, the token signs in only together with a matching JWT from the job, and each JWT is accepted once. The token itself is still stored in CI, so this is a binding rather than full keyless sign-in; the point is that a token copied out of CI is useless outside the matching job. The agent finds the job's JWT itself on all three providers.

Each cloud's setup, with working policies, is in CI/CD secrets with OIDC, and the OIDC trust policy builder writes policies for AWS, Google Cloud and Azure.

Sources

• Google Cloud: Workload Identity Federation, checked October 30, 2026.
• AWS IAM: Create a role for OpenID Connect federation, checked October 30, 2026.