Instead of creating and downloading a service account key (which then needs storing, rotating, and never leaking), impersonate the service account with your own user credentials.
Per command:
```
gcloud storage buckets list --impersonate-service-account [SA-EMAIL]
```
Or set it for the whole config:
```
gcloud config set auth/impersonate_service_account [SA-EMAIL]
```
What you need on the target service account: the iam.serviceAccounts.getAccessToken permission, which comes with roles/iam.serviceAccountTokenCreator (Service Account Token Creator). Grant it to your user or your CI identity:
```
gcloud iam service-accounts add-iam-policy-binding [SA-EMAIL] --member user:[YOUR-EMAIL] --role roles/iam.serviceAccountTokenCreator
```
Why impersonation beats keys:
- No secret material to store. The tokens are short-lived and minted on demand.
- Revoking is one IAM binding change, not a key hunt across repos and laptops.
- Audit logs show who impersonated whom.
Limits to know:
- Impersonated tokens last about an hour by default. Long-running jobs should mint fresh tokens or use a directly attached service account.
- The impersonating identity still needs the underlying API permissions through the service account; impersonation only changes WHO you act as, not WHAT you can do.
- Some tools that shell out to gcloud inherit the flag fine; tools that need raw ADC need the client-library impersonation path instead (see the companion skill).
Verify: run a read-only command with the flag and check the caller identity in the audit log, or use `gcloud auth print-identity-token` with impersonation to inspect claims.