Workload Identity Federation

Trading outside tokens for Google credentials

Workloads outside Google Cloud, such as a GitHub Actions job, an AWS workload or an on-premises server, still need to call Google APIs. Workload Identity Federation lets them do so without service account keys. You create a workload identity pool and a provider that trusts an external identity provider (GitHub's OIDC issuer, AWS, Azure or any OIDC/SAML provider), with an attribute condition such as "only repository acme/shop". The external token is exchanged through the Security Token Service for a short-lived Google credential, either used directly as a federated principal or to impersonate a service account. Inside GKE, Workload Identity Federation for GKE maps Kubernetes service accounts to IAM principals, so pods get identities without node-wide credentials.

GitHub Actions authenticating with federation

Only resource names are stored in the workflow; there is no secret to rotate.

permissions:
  contents: read
  id-token: write          # lets the job request an OIDC token

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: projects/123456789/locations/global/workloadIdentityPools/github/providers/github-oidc
          service_account: deployer@shop-prod-654321.iam.gserviceaccount.com
      - uses: google-github-actions/setup-gcloud@v2
      - run: gcloud run deploy orders-api --source . --region asia-south1

Always set an attribute condition

A GitHub provider without a condition on assertion.repository (or the repository owner) could accept tokens from any repository on GitHub. Restrict the provider to your organization and repository, and the binding to the right branch or environment.

Quick check: What does Workload Identity Federation remove the need for?

• Long-lived service account keys for external workloads
• IAM roles
• Projects
• Audit logs