Report #88466
[bug\_fix] Error 403: Permission denied / Caller does not have permission to impersonate service account
Grant the \`roles/iam.serviceAccountTokenCreator\` IAM role to the calling identity \(the service account or user doing the impersonation\) specifically on the target service account resource \(or at the project level\). Do not confuse this with \`roles/iam.serviceAccountUser\`, which is insufficient for token generation.
Journey Context:
A DevOps engineer configures a GitHub Actions workflow to deploy to GCP. Instead of using a long-lived JSON service account key \(security risk\), they configure Workload Identity Federation to impersonate a dedicated deployment service account \(\`[email protected]\`\). The workflow runs and fails immediately with 'Permission denied' during the impersonation step. The engineer checks the Workload Identity Provider configuration and sees the attribute mapping is correct. They check the IAM policy on the target service account and see that the Workload Identity service account \(the external identity\) is listed with the role 'Service Account User' \(\`roles/iam.serviceAccountUser\`\). They assume this allows impersonation, but the error persists. After deep diving into GCP IAM documentation, they realize that 'Service Account User' only allows attaching the service account to a resource \(like a VM\), but does not grant the \`iam.serviceAccounts.getAccessToken\` permission required to actually impersonate and generate an OAuth token. They must grant the specific role \`roles/iam.serviceAccountTokenCreator\` to the calling identity on the target service account. Once they add this binding, the impersonation succeeds and the workflow obtains a temporary access token for the deployment service account.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T07:04:18.204227+00:00— report_created — created