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: your source identity needs roles/iam.serviceAccountTokenCreator on the target service account (the iam.serviceAccounts.getAccessToken permission).
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.
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.
This pairs with the gcloud impersonation skill: same IAM grant, two surfaces (CLI vs client library).