15.3 Service Account Impersonation & Short-Lived Credentials

Why This Matters

Two official exam-guide bullets sit under domain 5.2: "Managing service account impersonation" and "Creating and managing short-lived service account credentials." Modern Google Cloud security guidance has shifted hard away from downloadable service account keys and toward impersonation and Workload Identity Federation -- expect several scenario questions that reward picking the keyless option over the key-based one.

What Is Impersonation?

Service account impersonation lets an authorized principal (a user or another service account) temporarily "become" a service account and make API calls with its permissions -- without ever downloading a long-lived key file. The permission required is iam.serviceAccounts.getAccessToken, bundled in the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator).

gcloud storage ls gs://finance-reports \
  --impersonate-service-account=billing-exporter@acme-prod.iam.gserviceaccount.com

You can also set it as a persistent CLI default:

gcloud config set auth/impersonate_service_account \
  billing-exporter@acme-prod.iam.gserviceaccount.com

Short-Lived Credentials: The Types and Lifetimes

The Service Account Credentials API issues several kinds of temporary credentials, all generated on demand and never stored on disk long-term:

An access token obtained by impersonation has no refresh token -- once it expires, the caller simply repeats the impersonation call to mint a new one. This is a deliberate design choice: nothing long-lived sits on disk to be stolen.

Exam trap: deleting a service account key does not revoke short-lived credentials that were already issued from that key before deletion. If you suspect a key is compromised, deleting the key stops future misuse but does not retroactively invalidate tokens already handed out.

Service Account Keys: The Last Resort

For comparison, keys remain available but are explicitly the least-preferred authentication option:

• A service account can hold a maximum of 10 keys.
• JSON is the recommended format; P12 exists only for legacy compatibility.
• Since May 3, 2024, new organizations have the iam.disableServiceAccountKeyCreation constraint enforced by default, blocking key creation unless a project is explicitly exempted.
• Google's authentication decision order is: (1) user credentials via Application Default Credentials during development, (2) an attached service account for workloads running on Google Cloud, (3) Workload Identity Federation for workloads running outside Google Cloud, and only as a last resort, (4) a downloaded service account key.

Workload Identity Federation

Workload Identity Federation solves the specific problem of external workloads -- a GitHub Actions pipeline, an AWS Lambda function, an on-premises server -- needing to call Google Cloud APIs without ever holding a Google Cloud credential. Instead, it exchanges the workload's existing identity token (from GitHub, AWS, Okta, Active Directory, and similar providers) for a short-lived Google credential:

1. You create a workload identity pool (one per external environment).
2. You add a provider inside that pool for the specific identity source (for example, GitHub's OIDC issuer).
3. The external workload presents its native token; Google's Security Token Service (STS) validates it and returns a federated token.
4. That federated token is either (a) granted IAM roles directly on Google Cloud resources, or (b) exchanged again, via impersonation, for a token belonging to an intermediary service account.

GKE Workload Identity Federation

Inside GKE, the same idea binds a Kubernetes ServiceAccount (KSA) to a Google Cloud service account (GSA) so Pods get real Google Cloud permissions without mounting a key file into the container. Two things are required together -- neither alone is sufficient:

# 1. IAM policy binding granting the KSA permission to impersonate the GSA
gcloud iam service-accounts add-iam-policy-binding \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"

# 2. Annotation on the KSA linking it to the GSA
kubectl annotate serviceaccount KSA_NAME \
  --namespace NAMESPACE \
  iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Exam Scenario

A CI/CD job running in GitHub Actions needs to push container images to Artifact Registry on every merge to main. The team's current pipeline downloads a service account JSON key stored as a GitHub secret. What should the ACE-certified engineer recommend instead?

Configure a workload identity pool and provider trusting GitHub's OIDC token issuer, grant the mapped identity permission to push to Artifact Registry (directly, or via impersonating a scoped service account), and delete the stored key -- removing a long-lived secret from the pipeline entirely.

Takeaways

• Impersonation (--impersonate-service-account) requires roles/iam.serviceAccountTokenCreator and needs no downloaded key.
• OAuth 2.0 access tokens default to a 1-hour lifetime, extendable to 12 hours only via an explicit organization policy constraint.
• A service account can hold at most 10 keys, and new organizations created since May 3, 2024 block key creation by default.
• Workload Identity Federation exchanges an external identity's own token for a short-lived Google Cloud credential, eliminating the need for a downloaded key.
• GKE Workload Identity Federation requires both an IAM binding (roles/iam.workloadIdentityUser) and a matching KSA annotation -- either alone is not enough.