What is Service Account Impersonation?

Definition

Service account impersonation in Google Cloud is the ability of a principal (user or another service account) to act as a target service account temporarily, by obtaining short-lived credentials for it via the IAM Credentials API.

It eliminates the need for service account keys (long-lived JSON files), reduces credential leak risk, and provides a clear audit trail for delegated access.

In simple terms:

Impersonation lets an authorized principal "become" a service account for a short window — without ever holding its long-lived credentials.

---

Why Impersonation Matters

• Eliminates service account keys — the top GCP credential leak vector.
• Provides short-lived credentials (default 1 hour, max 12).
• Generates audit logs of every impersonation event.
• Enables clean cross-project / cross-team delegation.
• Foundation of Workload Identity Federation flows.

---

Required IAM Roles

To impersonate a service account, the principal needs roles on the target service account:

• roles/iam.serviceAccountTokenCreator — create access tokens, ID tokens, sign blobs/JWTs as the service account.
• roles/iam.serviceAccountUser — required to attach the service account to certain resources or use it in some operations.
• roles/iam.workloadIdentityUser — for Workload Identity Federation impersonation.

---

How It Works

Manual (User → Service Account)

gcloud auth login
gcloud config set auth/impersonate_service_account \
  [email protected]
gcloud storage ls

The CLI calls iamcredentials.generateAccessToken for the target SA, then uses the resulting short-lived token.

Programmatic (Service Account → Service Account)

from google.auth import impersonated_credentials

target_credentials = impersonated_credentials.Credentials(
  source_credentials=source_credentials,
  target_principal="[email protected]",
  target_scopes=["https://www.googleapis.com/auth/cloud-platform"],
  lifetime=3600,
)

Workload Identity Federation

External (non-Google) workload presents OIDC/SAML token → trades for impersonation of a service account.

---

Use Cases

1. CI/CD Without Keys

GitHub Actions / GitLab → Workload Identity Federation → impersonate cicd-deploy-sa. No long-lived keys.

2. Cross-Project Access

Service account in project A impersonates service account in project B (with permissions in B). Maintains separation of duties.

3. Just-In-Time Admin

User impersonates prod-admin-sa for the duration of their incident response, with full audit.

4. Local Development

Engineer authenticates as themselves; SDK impersonates dev-sa for testing — no key on disk.

5. SOC Investigation

Security team impersonates audit-sa to perform read-only investigations across projects.

---

Audit and Visibility

Every impersonation event is logged in Cloud Audit Logs (Admin Activity logs). The log shows:

• The principal who impersonated.
• The target service account.
• The action taken under the impersonation.

This allows attribution back to the human or source service account, even when actions are performed via the target SA.

---

Common Risks

1. Broad Token Creator Assignment

roles/iam.serviceAccountTokenCreator granted at project or org level (rather than per-SA) lets the principal impersonate any SA in that scope.

2. Impersonation Chains

User → low-priv SA (Token Creator) → mid-priv SA (Token Creator) → high-priv SA (Owner). Multi-step privilege escalation.

3. Lateral Movement via Impersonation

Compromised low-priv SA with Token Creator on multiple SAs enables lateral movement across the project.

4. Long Token Lifetime

Default is 1 hour; misconfigured to 12 hours widens the compromise window.

5. Impersonation Without Audit Review

If audit logs aren't reviewed, impersonation misuse goes undetected.

---

Real-World Examples

1. Privilege Escalation Chain

[email protected] had Token Creator on tools-sa. tools-sa had Token Creator on prod-sa. prod-sa was Owner on production project. Two impersonation steps = production Owner. Discovered in audit; chain disabled.

2. CI/CD Migration to Impersonation

Team replaced 40+ service account keys (stored as CI secrets) with Workload Identity Federation + impersonation. Reduced credential leak risk dramatically.

3. Audit-Friendly Investigation

SOC investigation impersonated audit-sa (read-only across projects). Every action logged with the SOC analyst's identity preserved as the impersonating principal.

4. Token Creator Sprawl

Org audit found 300+ Token Creator bindings, many at project level. Cleanup reduced to <50, all per-specific-SA, with documented purpose.

---

Best Practices

1. Eliminate service account keys in favor of impersonation / Workload Identity Federation.
2. Token Creator assigned per specific SA, not project- or org-wide.
3. Audit Token Creator chains for privilege escalation paths.
4. Short token lifetimes (1 hour default).
5. Use Workload Identity Federation for external workloads.
6. Audit logs centralized and reviewed — alert on unusual impersonation patterns.
7. Org Policy to disable service account key creation where not needed.
8. Document impersonation patterns in runbooks.
9. Quarterly review of Token Creator bindings.
10. Approval workflows for high-privilege SA impersonation.

---

Checklist

• Service account keys minimized?
• Token Creator scoped per-SA?
• Impersonation chains audited (no escalation paths)?
• Token lifetimes ≤ 1 hour where possible?
• Workload Identity Federation in CI/CD and external workloads?
• Audit logs centralized and reviewed?
• Org Policy disabling key creation?
• Quarterly Token Creator review?
• Approvals required for sensitive SA impersonation?

---

How Forestall Helps

Forestall identifies:

• All Token Creator bindings.
• Impersonation chains across projects.
• Privilege escalation paths via impersonation.
• Service account keys that can be replaced by impersonation/federation.
• Audit log anomalies for impersonation events.

---

Frequently Asked Questions

Is impersonation the same as actAs?

iam.serviceAccountUser (sometimes called actAs) is required for using a SA in some contexts (attaching to resources). Impersonation specifically uses Token Creator + IAM Credentials API.

Can a service account impersonate itself?

Indirectly — service accounts attached to a resource get tokens automatically. Explicit self-impersonation is unusual.

Is impersonation logged?

Yes — Admin Activity audit logs capture every impersonation event.

What's the default token lifetime?

1 hour for access tokens (configurable up to 12 hours).

Can I prevent impersonation?

Restrict Token Creator role narrowly; use Org Policy to disable key creation; use Deny policies to prevent unwanted impersonation.

---

Conclusion

Service account impersonation is the modern, secure way to delegate access to Google Cloud workloads and humans without distributing long-lived keys. Used carefully — with narrow Token Creator bindings, audit log review, short lifetimes, and federation for external workloads — it eliminates a major credential-leak risk and provides clean attribution. Used carelessly — with sprawling Token Creator and unmanaged chains — it becomes a hidden privilege escalation channel. Govern impersonation continuously, and it becomes one of GCP's strongest security primitives.