Your GKE workloads need to access BigQuery and Cloud Storage without using service account key files. Explain how Workload Identity Federation works in GKE, how you set it up, and what changes when federating with external identity providers like AWS or GitHub Actions.

GKE Workload Identity Mechanism

Workload Identity is the recommended way for GKE pods to authenticate to GCP services. It works by creating a binding between a Kubernetes ServiceAccount (KSA) and a GCP IAM service account (GSA). When a pod uses the bound KSA, the GKE metadata server intercepts calls to the instance metadata endpoint (169.254.169.254) and returns a short-lived OAuth2 token for the GSA instead of the node's service account token. This eliminates the need to create, rotate, and distribute service account key JSON files.

Security Benefits Over Key Files

Service account key files are the number one source of GCP credential leaks. They don't expire (by default 10-year validity), can be copied and used from anywhere, and are frequently committed to version control or embedded in container images. Workload Identity tokens are automatically rotated (1-hour TTL), scoped to a specific pod identity, and never written to disk. The principle of least privilege is enforced through IAM bindings rather than file distribution.

External Workload Identity Federation

For workloads outside GCP (AWS EC2, GitHub Actions, GitLab CI, on-prem Kubernetes), Workload Identity Federation uses a Workload Identity Pool that trusts an external OIDC or SAML provider. When a GitHub Actions workflow runs, it receives a GitHub OIDC token. This token is exchanged with GCP's Security Token Service (STS) for a federated access token, which is then used to impersonate a GCP service account. No long-lived credentials are stored in GitHub Secrets.

Attribute Mapping and Conditions

Workload Identity Federation supports attribute conditions that restrict which external identities can authenticate. For GitHub Actions, you can restrict access to specific repositories, branches, or environments using claims from the OIDC token (e.g., assertion.repository == 'myorg/myrepo' && assertion.ref == 'refs/heads/main'). This prevents any other GitHub repository from assuming your GCP service account.

Production Considerations

Enable Workload Identity at cluster creation—retrofitting requires node pool recreation. Each namespace/KSA combination maps to a different GSA, enabling per-service IAM granularity. Monitor iam.googleapis.com/WorkloadIdentityPool audit logs for federation events. Be aware of the metadata server latency (~50ms for first token acquisition) which can affect cold start times.