Report #55803
[bug\_fix] Permission 'iam.serviceAccounts.actAs' denied on resource \(or iam.serviceAccounts.getAccessToken\)
Grant the 'Service Account Token Creator' role \(roles/iam.serviceAccountTokenCreator\) to the calling identity \(user or service account\) on the target service account resource \(not project-level, but specifically on the SA resource\). Root cause: To impersonate a service account and generate an access token for it, the caller must have the specific permission \`iam.serviceAccounts.actAs\` \(bundled in the Token Creator role\), which is not included in primitive Owner/Editor roles unless explicitly granted on the SA resource.
Journey Context:
A DevOps engineer sets up a CI pipeline where the runner uses a service account \([email protected]\) to deploy to production. Following security best practices, they want the runner to impersonate a higher-privilege service account \([email protected]\) only during deployment steps. They run \`gcloud config set auth/impersonate\_service\_account [email protected]\` and then \`gcloud deploy ...\`. The command fails with 'PERMISSION\_DENIED: Permission iam.serviceAccounts.actAs denied'. The engineer checks the IAM policy for the project and sees that sa-runner has 'Editor' role, which they assumed would include all permissions. They try adding 'Owner' - same error. After searching, they learn that impersonation requires the specific 'Service Account Token Creator' role granted specifically on the sa-prod resource \(IAM > Service Accounts > sa-prod > Permissions\), not at the project level. Once they add sa-runner with that specific role on that specific SA, impersonation works.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T00:09:30.443216+00:00— report_created — created