Impersonation, short-lived credentials, and Workload Identity

An authenticated principal (a user or another service account) gets a token for the service account and uses it to act as that account, with all its permissions. There are always two identities: the impersonator and the impersonated account. It's similar to AWS AssumeRole.

• Required permission: iam.serviceAccounts.getAccessToken, included in Service Account Token Creator (roles/iam.serviceAccountTokenCreator).
• Uses: temporary elevated access without changing policies, testing whether a set of permissions is enough, developing locally apps that only work as a service account, and authenticating external apps.
• In the console you always authenticate with your user credentials: you can't impersonate a service account there.
• Using an attached account or a key isn't impersonation: only the account's identity is involved.

gcloud iam service-accounts add-iam-policy-binding \
  deployer@my-project.iam.gserviceaccount.com \
  --member=user:ana@example.com --role=roles/iam.serviceAccountTokenCreator

Impersonation with gcloud and ADC

# A single command
gcloud storage buckets list \
  --impersonate-service-account=deployer@my-project.iam.gserviceaccount.com

# Every gcloud command
gcloud config set auth/impersonate_service_account \
  deployer@my-project.iam.gserviceaccount.com

# Client libraries on your machine (ADC file)
gcloud auth application-default login \
  --impersonate-service-account deployer@my-project.iam.gserviceaccount.com

In all three cases gcloud requests short-lived credentials for the service account and makes the calls with them.

Short-lived credentials

According to Google, they are the most secure way to authenticate as a service account: an OAuth 2.0 access token that expires after 1 hour by default and isn't refreshed automatically. They carry less risk than keys.

• Often they are obtained automatically: with --impersonate-service-account, with an account attached to a VM (client libraries use ADC), or with Workload Identity Federation.
• The Service Account Credentials API creates them manually: OAuth 2.0 access tokens, OpenID Connect ID tokens, self-signed JWTs, and self-signed blobs.
• An access token's maximum lifetime can be extended to 12 hours by adding the account to the iam.allowServiceAccountCredentialLifetimeExtension constraint. ID tokens last 1 hour.
• Self-impersonation isn't allowed: using an account's short-lived token to generate another token for the same account (except with self-signed JWTs), so a stolen token can't be refreshed indefinitely.
• Credential Access Boundaries downscope a short-lived token's permissions, but only for Cloud Storage.

Impersonation and audit logs

Application Default Credentials

ADC is the strategy the libraries use to find credentials automatically based on the environment, so the same code works in development and production. Search order:

1. The GOOGLE_APPLICATION_CREDENTIALS environment variable (a Workload or Workforce Identity Federation configuration file, or a key, which isn't recommended).
2. The file created with gcloud auth application-default login.
3. The attached service account, returned by the metadata server.

The order doesn't say which is better; only where it looks first.

Gives on-premises or multicloud workloads access to Google Cloud with federated identities, without service account keys. It works with AWS, Azure, on-premises Active Directory, GitHub, GitLab, X.509 certificates, and any IdP that supports OIDC or SAML 2.0.

• The IdP gives a credential to the Security Token Service, which verifies it and returns a federated token (OAuth 2.0 token exchange).
• Google recommends direct access: grant roles to principal://… or principalSet://… on resources. The alternative is impersonating a service account, which needs roles/iam.workloadIdentityUser.
• Granting access to every identity in the pool is risky: limit it with attributes and conditions.
• The external app uses a credential configuration file, not a key.

It's the recommended way for pods to access Google Cloud APIs: each app has its own identity and gets roles through IAM, with no key files. Google manages the pool and provider.

• When you enable it, GKE creates the fixed pool PROJECT_ID.svc.id.goog, registers the cluster as a provider, and deploys the GKE metadata server on every node.
• Enabling it grants no permissions: you must give roles to the Kubernetes ServiceAccount.
• On Autopilot every node always uses it. On Standard you enable it on the cluster and on each node pool.

gcloud container clusters update my-cluster --location=europe-west1 \
  --workload-pool=my-project.svc.id.goog
gcloud container node-pools update default-pool --cluster=my-cluster \
  --location=europe-west1 --workload-metadata=GKE_METADATA

# Give access to the Kubernetes ServiceAccount "reader" in namespace "app"
gcloud storage buckets add-iam-policy-binding gs://app-data --role=roles/storage.objectViewer \
  --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/my-project.svc.id.goog/subject/ns/app/sa/reader

Workforce Identity Federation

Federates users (employees, partners, contractors) from an external OIDC or SAML 2.0 IdP (Entra ID, AD FS, Okta…) so they sign in to Google Cloud with SSO. It doesn't store accounts in Google Cloud, so no sync is needed with Google Cloud Directory Sync. Workforce identity pools are configured at the organization level and access is granted with allow policies.

Exam scenarios

Common exam traps