How does Workload Identity Federation eliminate service account 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.

What attribute mappings and conditions should I configure?

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.

Can I use Workload Identity Federation with GKE?

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.

GCP Workload Identity Config Builder

IAM & SecurityGCP

Build Workload Identity Federation configurations for keyless authentication from external providers.

Workload Identity Federation Configuration

Build Workload Identity Federation configurations for keyless authentication from external identity providers.

Required Fields

workloadIdentityPoolworkloadIdentityPool.nameproviderprovider.attributeMapping

{
  "workloadIdentityPool": {
    "name": "projects/123456789/locations/global/workloadIdentityPools/github-actions-pool",
    "displayName": "GitHub Actions Pool",
    "description": "Workload identity pool for GitHub Actions CI/CD",
    "disabled": false
  },
  "provider": {
    "name": "projects/123456789/locations/global/workloadIdentityPools/github-actions-pool/providers/github-provider",
    "displayName": "GitHub OIDC Provider",
    "description": "GitHub Actions OIDC identity provider",
    "attributeMapping": {
      "google.subject": "assertion.sub",
      "attribute.repository": "assertion.repository",
      "attribute.repository_owner": "assertion.repository_owner",
      "attribute.actor": "assertion.actor",
      "attribute.ref": "assertion.ref"
    },
    "attributeCondition": "assertion.repository_owner == 'my-org'",
    "oidc": {
      "issuerUri": "https://token.actions.githubusercontent.com",
      "allowedAudiences": ["https://iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/github-actions-pool/providers/github-provider"]
    }
  },
  "serviceAccountBinding": {
    "serviceAccount": "deploy-sa@my-project.iam.gserviceaccount.com",
    "members": [
      "principalSet://iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/github-actions-pool/attribute.repository/my-org/my-repo"
    ],
    "role": "roles/iam.workloadIdentityUser"
  }
}

Generated Output

Output will appear here...

About This Tool

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.

When to Use This Tool

•Configuring Workload Identity Federation for GitHub Actions so CI/CD pipelines can deploy to GCP without storing service account keys as repository secrets
•Setting up AWS-to-GCP federation that allows EC2 instances with specific IAM roles to access Cloud Storage buckets
•Building attribute condition expressions that restrict access to specific GitHub repositories, branches, or environments
•Generating Terraform configurations for Workload Identity pools and providers with correct OIDC or AWS provider settings

Frequently Asked Questions

How does Workload Identity Federation eliminate service account 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.
What attribute mappings and conditions should I configure?: 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.
Can I use Workload Identity Federation with GKE?: 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.

Related Learning Guides

IAM & Organization Policies26 min read

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.