Courses GCP securityWorkload identity & IR

Workload Identity Federation

Keyless CI and per-pod GKE identity.

Advanced35 min · lesson 13 of 15

The highest-leverage GCP identity upgrade is the same as everywhere: delete the long-lived keys. On GCP that means never downloading a service-account key, and instead letting external and in-cluster workloads exchange an attested identity for short-lived credentials.

Workload Identity Federation for external CI

Workload Identity Federation lets a workload outside GCP — GitHub Actions, GitLab, another cloud — present its native OIDC or SAML token to a workload identity pool, which exchanges it for short-lived GCP credentials with no key downloaded. You configure the pool with an attribute mapping and a condition that pins the token to a specific repository and ref, so a fork or another repo cannot obtain credentials. The result is the same as AWS OIDC federation: nothing static to leak, and access scoped to the real workload.

GitHub Actions → GCP, no key

# A pool + provider that only trusts one repo, mapped by the token's claims.
gcloud iam workload-identity-pools providers create-oidc gh \
  --workload-identity-pool=ci-pool --location=global \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repo=assertion.repository" \
  --attribute-condition="assertion.repository=='acme/api'"
 
# Let that federated identity impersonate a scoped deploy SA — no key file:
gcloud iam service-accounts add-iam-policy-binding [email protected] \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/NUM/locations/global/workloadIdentityPools/ci-pool/attribute.repo/acme/api"

GKE Workload Identity for pods

Inside GKE, Workload Identity maps a Kubernetes service account to a Google service account, so each pod gets exactly the GCP access its workload needs instead of borrowing a broad node service account. A compromised pod then inherits only that one scoped identity, and there is no node key to steal. Bind the KSA to the GSA, annotate the KSA, and the metadata server delivers short-lived, auto-rotated credentials transparently.

Attested identity → short-lived creds

1workload (CI job / pod)

has a native identity

2OIDC token / KSA token

signed claims: repo, ref, sa

3pool / Workload Identity

verifies + conditions

4short-lived GCP creds

scoped, auto-rotated, no key

A captured token that expired is worthless, and there was never a static key to steal. Pin the conditions like production code.

A loose attribute condition is a wide-open door

Federation security lives entirely in the provider’s attribute condition. Trusting assertion.repository_owner without pinning the repository, or omitting the condition, lets any repo in the org — or a fork’s pull request — mint credentials. Pin to specific repos/refs and review these conditions as carefully as any IAM grant.

Detection as code & responseOrg policy & landing zones