GCP IAM Attack Paths and How to Close Them

Cloud Security

GCP IAM looks simpler than AWS until you trace service account impersonation across projects. Here are the paths we exploit on engagements and the controls that actually stop them.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 29, 2025 · 7 min read

Google Cloud's IAM model centers on service accounts. Almost every privilege escalation we find on GCP engagements involves either impersonating a service account that has more rights than the caller, or attaching such a service account to a runtime where the caller can execute code.

How attackers find this

We enumerate with gcloud and scout-suite-gcp first, then move to gcphound for graph analysis. The two questions we are answering: which principals have iam.serviceAccounts.getAccessToken or iam.serviceAccounts.signJwt against which service accounts, and which principals have iam.serviceAccounts.actAs against service accounts that other services will accept.

• Direct impersonation: iam.serviceAccounts.getAccessToken on a high-privilege SA mints OAuth tokens for that SA.
• actAs across projects: a Compute Admin in project A who has actAs on a service account in project B can attach that SA to a VM in A and read tokens from the metadata server.
• Cloud Functions or Cloud Run deploy: deploying a function with a chosen runtime SA executes attacker code as that SA on the next invocation.
• Workflows and Cloud Build: similar shape, attach a privileged SA to a job you control.
• GCS bucket discovery via GCPBucketBrute reveals public or weakly ACL'd buckets that often hold service account keys.

Methodology in practice

On engagements we frequently find a developer with broad Editor on a 'sandbox' project plus actAs on a service account that was, at some point, granted Owner on production. That is the path: deploy a Cloud Function in sandbox attached to the prod-bound SA, invoke it, mint tokens, pivot. The actAs grant is two years old, the developer left the team eighteen months ago, the project is unreviewed.

Detection

Cloud Audit Logs (Admin Activity is on by default; Data Access is not on every API and you should enable it for IAM and Resource Manager). The events that matter: GenerateAccessToken, GenerateIdToken, SignBlob, SignJwt with a caller principal that does not normally impersonate the target SA. Set up log sinks into a security project with BigQuery and write detections that look at the cross-product of caller identity and target service account.

Remediation

1. Move workloads to Workload Identity Federation so external CI systems mint short-lived tokens through OIDC instead of holding service account keys.
2. Restrict iam.serviceAccounts.actAs to specific service accounts using IAM conditions; never grant it broadly.
3. Use a project-level organization policy constraint (iam.disableServiceAccountKeyCreation) to block long-lived keys outside an explicit allowlist.
4. Enable VPC Service Controls around production projects so impersonation tokens are useless from outside the perimeter.
5. Audit cross-project IAM bindings quarterly; treat any binding from a non-prod project to a prod SA as a finding.
6. Turn on Recommender for IAM to surface unused permissions and rotate them out.

GCP rewards tight project boundaries. The cleanest production environments we have seen treat each project as a security domain, with explicit, audited bindings between them and no shared service accounts.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.