Service accounts & impersonation

Killing keys and scoping the escalation path.

Service accounts are where most GCP privilege escalation and credential leakage live. The two habits to break are downloading service-account keys and granting impersonation too broadly — both turn a scoped identity into a durable, transferable, or escalatable credential.

Kill the downloaded keys

A downloaded service-account key is a long-lived JSON bearer credential that never expires — commit it once and it is compromised forever. Prefer attached identities (the SA a resource runs as), Workload Identity Federation for external CI, and impersonation for humans, none of which produce a static key. Enforce the org policy constraint that disables SA key creation entirely, so the leak path cannot be opened even by mistake.

# Org-wide guardrail: no downloadable SA keys anywhere below this node.
gcloud resource-manager org-policies enable-enforce \
  constraints/iam.disableServiceAccountKeyCreation --organization=ORG_ID
 
# Need to act as a service account? Impersonate for a short-lived token —
# no key file, fully logged as a generateAccessToken call.
gcloud storage ls gs://payments-prod-data \
  --impersonate-service-account=reporter@payments-prod.iam.gserviceaccount.com

Impersonation is the escalation path to watch

roles/iam.serviceAccountTokenCreator is GCP’s equivalent of AWS PassRole: a principal who can mint tokens for a powerful service account inherits its permissions. Granted project-wide, it lets someone impersonate any SA in the project — including highly-privileged ones. Always grant it on specific service accounts, never at the project or org level, and treat the default Compute Engine and App Engine service accounts (historically Editor) as something to lock down or replace with least-privilege SAs.