Impersonation, Short-Lived Credentials and Workload Identity

What it is

The safest credentials are the ones that expire quickly and are never downloaded. Service account impersonation lets a user or another service account act as a service account temporarily. Short-lived credentials (access tokens, ID tokens, signed JWTs) replace long-lived keys. Workload Identity Federation for GKE lets Kubernetes workloads use IAM identities, and Workload Identity Federation lets workloads outside Google Cloud (AWS, Azure, on premises, CI/CD systems) access Google Cloud without keys.

How it works

Service account impersonation

A principal with Service Account Token Creator (roles/iam.serviceAccountTokenCreator) on a service account can obtain short-lived tokens for it and act as it.

# grant a group permission to impersonate the deploy service account
gcloud iam service-accounts add-iam-policy-binding \
  deployer@shop-prod-1234.iam.gserviceaccount.com \
  --member="group:release-managers@example.com" \
  --role="roles/iam.serviceAccountTokenCreator"

# run one command as the service account
gcloud storage ls gs://releases-1234 \
  --impersonate-service-account=deployer@shop-prod-1234.iam.gserviceaccount.com

Benefits: users keep minimal personal permissions, privileged access is used only when needed, and audit logs record both the caller and the impersonated service account.

Short-lived credentials

The IAM Service Account Credentials API issues credentials that expire, by default within an hour for OAuth access tokens:

gcloud auth print-access-token --impersonate-service-account=deployer@shop-prod-1234.iam.gserviceaccount.com

Short-lived credentials limit the damage of a leak because they expire quickly and can be issued only to authorized callers.

Service accounts for GKE applications

Workload Identity Federation for GKE maps Kubernetes identities to IAM, so Pods call Google Cloud APIs without node-wide permissions or keys.

For a direct grant, the principal is principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME. The IAM member for a KSA in the second approach looks like serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]. Each workload gets only its own permissions, unlike sharing the node's service account.

Workload Identity Federation

Workload Identity Federation lets external workloads exchange their own credentials for short-lived Google tokens.

A worked scenario

A company removes all service account keys. Release managers impersonate a deployer service account when needed. GKE Pods use Workload Identity Federation for GKE, each with its own Kubernetes service account and minimal roles. The GitHub Actions pipeline authenticates through Workload Identity Federation with an OIDC provider restricted to the company's repository. An app on AWS reads a bucket through an AWS provider. The organization policy disabling key creation is then enforced.

How the exam asks about this

• "Act as a service account temporarily without a key." Impersonation, with Service Account Token Creator.
• "Pods need access to Cloud Storage with least privilege." Workload Identity Federation for GKE with a dedicated Kubernetes service account.
• "GitHub Actions must deploy to Google Cloud without stored keys." Workload Identity Federation with an OIDC provider.
• "Access a private Cloud Run service from a script." An ID token.