Skip to content
Latchkey

OIDC GCP "Unable to acquire impersonated credentials" in CI

google-github-actions/auth exchanged the OIDC token for a federated identity but could not impersonate the target service account. The provider attribute condition or the IAM binding on the service account does not permit this repository.

What this error means

The auth step fails with "Unable to acquire impersonated credentials" and a permission-denied detail for the service account. The OIDC exchange itself succeeded.

.github/workflows/ci.yml
Error: google-github-actions/auth failed with: failed to generate
Google Cloud federated token ... Unable to acquire impersonated credentials:
... PERMISSION_DENIED

Common causes

The service account lacks the workloadIdentityUser binding

The GitHub principal is not granted roles/iam.workloadIdentityUser on the service account, so impersonation is denied.

The provider attribute condition rejects the repo

The WIF provider's attribute mapping or condition (for example on assertion.repository) does not match this repo, blocking the exchange.

How to fix it

Bind the GitHub principal to the service account

  1. Grant roles/iam.workloadIdentityUser on the service account to the WIF principalSet for your repo.
  2. Confirm the provider attribute condition allows assertion.repository.
  3. Re-run the auth step.
Terminal
gcloud iam service-accounts add-iam-policy-binding \
  gha@PROJECT.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "principalSet://iam.googleapis.com/projects/NUM/locations/global/workloadIdentityPools/POOL/attribute.repository/my-org/my-repo"

Pass the correct provider and service account

Reference the full provider resource name and the service account to impersonate in the action.

.github/workflows/ci.yml
- uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: projects/NUM/locations/global/workloadIdentityPools/POOL/providers/PROVIDER
    service_account: gha@PROJECT.iam.gserviceaccount.com

How to prevent it

  • Bind workloadIdentityUser to the exact repo principalSet.
  • Keep the provider attribute condition aligned with assertion.repository.
  • Use the full provider resource path in the auth step.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →