Build Workload Identity Federation configurations for keyless authentication from external providers.
Last verified: May 2026
Build Workload Identity Federation configurations for keyless authentication from external identity providers.
Required Fields
workloadIdentityPoolworkloadIdentityPool.nameproviderprovider.attributeMappingOutput will appear here...The builder constructs a Workload Identity Pool resource + Provider resource (OIDC, AWS, or SAML), with attribute mapping (translating external claims to google.* attributes) and attribute condition (CEL expression filtering which identities can authenticate). It also generates the IAM binding granting roles/iam.workloadIdentityUser on a target service account, scoped to the federated identity. Output is gcloud iam workload-identity-pools commands and Terraform google_iam_workload_identity_pool* resources.
GCP Workload Identity Federation allows external workloads — from AWS, Azure, on-premises, or CI/CD platforms like GitHub Actions — to access Google Cloud resources without using long-lived service account keys. Configuration involves creating a Workload Identity Pool, adding providers that map external identity attributes to Google Cloud identities, and defining IAM bindings that grant permissions based on those mapped attributes. The Workload Identity Config Builder helps you set up pools, providers, attribute mappings, and condition expressions for common identity federation scenarios.
Your team is migrating CI/CD from a service account JSON key stored in GitHub Secrets to Workload Identity Federation. The builder generates: a Workload Identity Pool 'github-actions-pool', an OIDC provider for token.actions.githubusercontent.com with attribute mapping `attribute.repository=assertion.repository`, and an attribute condition restricting to `org/repo` only. IAM binding grants impersonation rights on the deploy service account. After deploy, GitHub Actions workflows authenticate via OIDC tokens — no service account key in repo secrets. Annual security improvement: eliminated the most-stolen credential type for CI/CD.
GitHub Actions OIDC federation should ALWAYS use repository + branch attribute conditions. The default 'any GitHub identity can authenticate' is dangerous — anyone with a public GitHub account could obtain GCP tokens. The condition `assertion.repository == 'org/repo' && assertion.ref == 'refs/heads/main'` is the right minimum.
Workload Identity Federation pools can be paused (not deleted) if you suspect compromise. This is the WIF equivalent of revoking access — instantly invalidates all federated tokens issued from the pool without affecting other workloads.
When migrating from service account keys to WIF, run BOTH for a few weeks in parallel. If WIF auth fails for any reason (provider misconfiguration, attribute condition bug), the workload falls back to the key-based auth. Once you're confident WIF is working everywhere, delete the keys.
Instead of downloading a JSON key file, external workloads present their native identity token (OIDC token from GitHub Actions, AWS instance role credentials, Azure managed identity token, etc.) to the Security Token Service. GCP validates the token against the configured provider, evaluates attribute conditions, and issues a short-lived federated access token. The external workload uses this token to impersonate a service account and access GCP resources. No long-lived credentials are stored or rotated.
Attribute mappings translate external identity claims to Google Cloud attributes. Common mappings include google.subject (the unique identifier), attribute.repository (for GitHub), and attribute.aws_role (for AWS). Attribute conditions are CEL expressions that restrict which external identities can authenticate — for example, assertion.repository=='my-org/my-repo' limits access to a specific GitHub repository. Without conditions, any identity from the configured provider can obtain tokens.
GKE uses a related but different feature called GKE Workload Identity, which maps Kubernetes service accounts to Google Cloud service accounts. This is separate from Workload Identity Federation (which handles external-to-GCP federation). With GKE Workload Identity, pods automatically receive credentials for the mapped Google service account without mounting key files. Both features share the goal of eliminating long-lived credentials but address different use cases.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.