Eliminating Long-Lived Credentials with Workload Identity Federation in GCP

The Problem with Traditional Long-Lived Credentials

Traditional machine-to-machine authentication in cloud environments often relies on long-lived service account keys. These keys, typically JSON files, grant access to cloud resources. While convenient, they introduce significant security risks and operational overhead. If a key leaks, its blast radius is often unknown until extensive log analysis. Enforcing expiry dates creates a continuous rotation burden, often leading teams to disable expiry, further increasing risk by creating permanent access points that are difficult to revoke or audit.

Workload Identity Federation: A Trust-Based Solution

Workload Identity Federation (WIF) shifts the paradigm from managing secrets to configuring trust relationships. Instead of external systems storing and presenting static credentials, WIF allows Google Cloud Platform (GCP) to trust external identity providers (like GitHub, Harness, AWS STS). When an external workload needs access, it presents its *own native, short-lived token* to GCP's Security Token Service. GCP validates this token against pre-configured trust rules and, if valid, issues a short-lived GCP access token to the workload. This token expires automatically, eliminating the need for secret storage and rotation by the external system.

Architectural Components of WIF in GCP

• Workload Identity Pool: A container in a GCP project that groups external identity configurations. It's a logical grouping mechanism.
• Provider (or Connector): Configured within a pool, this defines the actual trust with an external identity system. It specifies the issuer URL, how to validate tokens (e.g., OIDC public keys), how to map external claims to GCP attributes, and crucially, attribute conditions.
• Service Account Binding: The final link, binding specific federated identities from the pool to a GCP service account. The external workload temporarily inherits the IAM permissions of this service account.

Attribute conditions are critical security gates. They are Common Expression Language (CEL) expressions that filter which specific identities from a trusted provider are allowed to authenticate, preventing overly broad access. For example, restricting access to a specific GitHub repository or Harness account.

Practical Adoption and Implementation Example (GitHub Actions)

The article highlights an organizational strategy of *mandating* WIF for all new GCP projects rather than attempting a risky, large-scale migration of existing keys. This approach reframes the problem of legacy keys from an ever-growing surface to a fixed, shrinking one. This also standardizes configurations across projects, simplifying future integrations.

gcloud iam workload-identity-pools create github-pool \
  --location="global" \
  --project=YOUR_PROJECT
gcloud iam workload-identity-pools providers create-oidc github-connector \
  --location="global" \
  --workload-identity-pool=github-pool \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository=='your-org/your-repo'" \
  --project=YOUR_PROJECT
gcloud iam service-accounts add-iam-policy-binding deploy-sa@YOUR_PROJECT.iam.gserviceaccount.com \
  --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/your-org/your-repo" \
  --role="roles/iam.workloadIdentityUser"