Impersonated credentials in Python: act as a service account without key files

TL;DR

When Python code must act as a service account but you refuse to ship a key file, build impersonated credentials on top of your existing ADC identity. `python import google.auth from google.auth import impersonated\_credentials source, \_ = google.auth.default() target = impersonated\_credentials.Credentials( source\_credentials=source, target\_principal="[SA-EMAIL]", target\_scopes=["https://www.googleapis.com/auth/cloud-platform"], lifetime=3600, ) from google.cloud import storage client = storage.Client(credentials=target, project="[PROJECT-ID]") ` Prerequisites, same as the gcloud flag:

Steps

1. When Python code must act as a service account but you refuse to ship a key file, build impersonated credentials on top of your existing ADC identity.

import google.auth
from google.auth import impersonated_credentials

source, _ = google.auth.default()
target = impersonated_credentials.Credentials(
 source_credentials=source,
 target_principal="[SA-EMAIL]",
 target_scopes=["https://www.googleapis.com/auth/cloud-platform"],
 lifetime=3600,
)

from google.cloud import storage
client = storage.Client(credentials=target, project="[PROJECT-ID]")

2. Prerequisites, same as the gcloud flag: your source identity needs roles/iam.serviceAccountTokenCreator on the target service account (the iam.serviceAccounts.getAccessToken permission).
3. Traps:

• target_scopes must cover every API you will call. cloud-platform scope is the broad one; narrower scopes fail with confusing 403s on APIs you did not list.
• lifetime maxes out and tokens expire; for daemons, rebuild credentials periodically or attach the SA directly to the workload instead.
• Do NOT wrap this in a helper that falls back to a key file path "for convenience". That fallback is how keys end up in repos.
• On Cloud Run, GKE, or GCE, skip impersonation entirely: attach the service account to the resource and let the metadata server do ADC.

4. How to confirm it works: call a harmless read (like listing buckets) and check the audit log for the service account as principal with your user as the impersonator.
5. This pairs with the gcloud impersonation skill: same IAM grant, two surfaces (CLI vs client library).

When to use

You are seeing this: That fallback is how keys end up in repos. - On Cloud Run, GKE, or GCE, skip impersonation entirely: attach the service account to the resource and let the metadata server do ADC. Use this skill when you run into "Impersonated credentials in Python: act as a service account without key files".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://www.googleapis.com/auth/cloud-platform"

Verified 2026-09-26 on the impersonation docs (role requirement, flag, short-lived tokens). The Python impersonated_credentials pattern is the documented client-library equivalent; scope and lifetime behavior confirmed against google-auth docs. Key-file avoidance is the documented best practice.