Service Account Key Files vs Impersonation Tokens

Google’s official position on service account key files is to use Workload Identity Federation instead. The security argument is legitimate, but the practical constraints of local development and AI agent workflows mean the recommendation does not always apply.

What Google Recommends and Why

Workload Identity Federation (WIF) lets an external identity provider vouch for your workload so Google can issue short-lived credentials without a static key file. GitHub Actions OIDC is the canonical example: when a CI job runs, GitHub asserts “this is workflow X from repository Y,” Google verifies that claim, and issues a temporary access token.

The security advantages are real:

• No static key file on disk that can be stolen, accidentally committed, or exposed through a log
• Short-lived tokens limit the window of exposure if credentials are captured
• Audit trails show both the human identity and the service account identity
• Revocation is immediate — no key rotation needed

WIF works well in CI/CD. It doesn’t work at all for local development because there’s no external identity provider to federate with. A developer laptop running dbt isn’t GitHub Actions. There’s no OIDC endpoint. The “no key files” recommendation is largely a CI/CD recommendation that gets applied universally.

Service Account Impersonation: The Middle Ground

Service account impersonation is the closest you can get to WIF for local development:

gcloud auth print-access-token \
  --impersonate-service-account=dbt-runner@acme-prod.iam.gserviceaccount.com

This command generates a 60-minute access token. No key file on disk. The audit trail shows your personal identity (you@example.com) impersonating the service account. Security teams like this because:

• No static credential to steal — the token expires
• Clear audit trail linking human and service account identities
• Individual revocation: if you leave the organization, your impersonation ability disappears

The constraints for agent workflows:

Tokens expire. A 60-minute token is fine for a dbt run. It’s a problem for a multi-hour Claude Code session or an automated pipeline that runs overnight. You need to refresh tokens, which requires your interactive identity — something agents can’t do on their own.

Setup overhead. The user account needs roles/iam.serviceAccountTokenCreator on the target service account. This is an additional IAM grant that needs to be managed.

# Grant yourself permission to impersonate the service account
gcloud iam service-accounts add-iam-policy-binding \
  dbt-runner@acme-prod.iam.gserviceaccount.com \
  --member="user:you@example.com" \
  --role="roles/iam.serviceAccountTokenCreator"

Key Files: The Pragmatic Choice

Service account JSON key files remain the most reliable option for local development and AI agent sessions:

# Create and download a key
gcloud iam service-accounts keys create ~/.gcp-keys/acme-dbt-runner.json \
  --iam-account=dbt-runner@acme-prod.iam.gserviceaccount.com

Set via environment variable and any tool that respects ADC picks it up:

export GOOGLE_APPLICATION_CREDENTIALS="$HOME/.gcp-keys/acme-dbt-runner.json"

Key files work in every scenario — interactive sessions, non-interactive environments, AI agents, sandboxed containers. They don’t expire mid-session. There’s no refresh problem.

The security risks are real and require active management:

Key files are static credentials. If one is stolen, it works until you revoke it. A compromised key can authenticate as the service account from anywhere.

AI agents log their activity. A poorly sanitized conversation log with Claude Code could expose a key path or even key contents if you’re discussing credentials during a session. This is the specific attack surface that makes short-lived tokens preferable for sensitive work.

Keys can be committed accidentally. Despite .gitignore entries, key files end up in repositories. Automated detection (GitGuardian, GitHub secret scanning) helps but doesn’t eliminate the risk.

Pragmatic Key Hygiene

If you’re using service account key files — and for most consulting workflows, you will be — do it with discipline:

One service account per client project. Created inside the client’s project, not in a shared project. If a key is compromised, it can only reach that one client’s resources.

# Create inside the client project, not a shared infrastructure project
gcloud iam service-accounts create dbt-runner \
  --display-name="dbt Runner" \
  --project=acme-analytics-prod

Minimum required roles. For dbt on BigQuery: roles/bigquery.user (run queries) and roles/bigquery.dataEditor (create tables in target datasets). Nothing broader.

gcloud projects add-iam-policy-binding acme-analytics-prod \
  --member="serviceAccount:dbt-runner@acme-analytics-prod.iam.gserviceaccount.com" \
  --role="roles/bigquery.user"

gcloud projects add-iam-policy-binding acme-analytics-prod \
  --member="serviceAccount:dbt-runner@acme-analytics-prod.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataEditor"

90-day rotation. New key, revoke old key, update references. Terraform’s time_rotating resource can automate this.

Filesystem permissions. Key files should not be world-readable.

chmod 600 ~/.gcp-keys/acme-dbt-runner.json

Excluded from cloud sync. ~/.gcp-keys/ should not be in iCloud, Google Drive, Dropbox, or any other sync service. And explicitly in .gitignore for any project that references key paths.

Assessment

For sensitive production work where credentials are being actively discussed (e.g., debugging sessions), impersonation tokens are preferable: no static file on disk and a clear audit trail.

For daily dbt builds across multiple client projects, including AI agent sessions that need persistent authentication, service account key files with proper hygiene are the more practical choice. Managing token refresh across multiple long-running agent sessions introduces operational complexity that typically outweighs the security improvement for most analytics engineering workflows.