Report #24669
[bug\_fix] 403 Permission 'iam.serviceAccounts.getAccessToken' denied on resource when impersonating GCP service accounts
Grant the calling service account the 'roles/iam.serviceAccountTokenCreator' IAM role on the target service account resource \(the one being impersonated\), not on the caller. Root cause: To impersonate a service account, the caller must have the iam.serviceAccounts.getAccessToken permission on the target SA resource. This is distinct from Service Account User \(roles/iam.serviceAccountUser\), which only allows attaching the SA to resources.
Journey Context:
A developer is building a CI pipeline that runs on Cloud Build using Service Account A. The pipeline needs to deploy to App Engine using Service Account B \(which has the App Engine Admin role\). The developer configures the Cloud Build step to impersonate Service Account B using the --impersonate-service-account flag or via the client libraries with impersonation config. The build fails with a 403 error stating 'Permission iam.serviceAccounts.getAccessToken denied on resource projects/PROJECT/serviceAccounts/[email protected]'. The developer checks IAM and sees that Service Account A has 'Service Account User' role on Service Account B, thinking this is sufficient for impersonation. After researching, they realize Service Account User only allows attaching the SA to Compute Engine instances, not generating access tokens for impersonation. They must grant 'Service Account Token Creator' \(roles/iam.serviceAccountTokenCreator\) to Service Account A on Service Account B. After updating the IAM policy, the impersonation works because the IAM check for iam.serviceAccounts.getAccessToken now passes, allowing the generateAccessToken API call to return a temporary access token for SA-B.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T19:48:45.413226+00:00— report_created — created