Report #10878
[bug\_fix] Permission 'iam.serviceAccounts.getAccessToken' denied on resource
Grant the calling identity \(user or service account\) the \`roles/iam.serviceAccountTokenCreator\` IAM role on the target service account that is being impersonated. This is in addition to any project-level Owner/Editor roles. Root cause: Service account impersonation in Google Cloud requires the explicit permission to generate access tokens \(\`iam.serviceAccounts.getAccessToken\`\) or sign JWTs \(\`iam.serviceAccounts.signJwt\`\) on the specific target service account resource. Project-level roles like Owner do not include these permissions on service accounts themselves, as they are considered high-privilege operations separate from resource management.
Journey Context:
A developer needs to run Terraform locally to deploy infrastructure in a production Google Cloud project. To maintain audit trails, they want Terraform to use a dedicated service account \(\`[email protected]\`\) rather than their personal credentials. They authenticate their local gcloud CLI with their personal account and set the environment variable \`GOOGLE\_IMPERSONATE\_SERVICE\_ACCOUNT\` to the Terraform service account email. When they run \`terraform plan\`, it fails with \`Error: Attempted to load application default credentials... impersonation failed... Permission iam.serviceAccounts.getAccessToken denied on resource [email protected]\`. The developer checks the IAM permissions for the Terraform service account and sees that their personal account has the \`Owner\` role at the project level. They assume this should grant all permissions, including impersonation. They search the error and find Google Cloud documentation stating that service account impersonation requires the specific \`roles/iam.serviceAccountTokenCreator\` role granted on the service account resource itself, not just project-level permissions. The developer realizes that Project Owner does not grant \`iam.serviceAccounts.getAccessToken\` on the service account resource. They run the gcloud command to bind the role: \`gcloud iam service-accounts add-iam-policy-binding [email protected] --member="user:[email protected]" --role="roles/iam.serviceAccountTokenCreator"\`. After the IAM binding propagates, Terraform successfully impersonates the production service account because the IAM check for \`getAccessToken\` now passes, and the plan executes with the correct audit identity.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T11:51:37.598826+00:00— report_created — created