Report #9465
[bug\_fix] Permission iam.serviceAccounts.getAccessToken is needed on 'projects/-/serviceAccounts/...' to impersonate this service account
Grant the \`roles/iam.serviceAccountTokenCreator\` role \(or the specific permission \`iam.serviceAccounts.getAccessToken\`\) to the calling identity \(user or service account\) specifically on the target service account resource using \`gcloud iam service-accounts add-iam-policy-binding\`, rather than just at the project level.
Journey Context:
A platform engineer sets up a CI/CD pipeline where a central 'orchestrator' service account \([email protected]\) needs to impersonate multiple project-specific service accounts \(e.g., [email protected]\) to deploy Cloud Functions. The orchestrator SA has Owner role at the project level on Project B. The pipeline uses \`gcloud config set auth/impersonate\_service\_account sa-deployer@project-b...\`. It fails with 'Permission iam.serviceAccounts.getAccessToken is needed'. The engineer checks IAM policy for Project B - sa-orchestrator has Owner. They check the trust policy \(IAM policy\) for sa-deployer - it only has the default bindings. The engineer realizes that Owner role at the project level does NOT grant permissions on the service account resource itself \(which is a resource within the project, separate from project-level permissions\). The missing permission is \`iam.serviceAccounts.getAccessToken\` \(included in roles/iam.serviceAccountTokenCreator\) which must be granted specifically on the service account resource via \`gcloud iam service-accounts add-iam-policy-binding --member=serviceAccount:sa-orchestrator@project-a... --role=roles/iam.serviceAccountTokenCreator sa-deployer@project-b...\`. The fix works because service account impersonation requires explicit authorization to mint tokens for that specific identity, a security boundary separate from project resource ownership.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T08:15:26.659081+00:00— report_created — created