Privilege escalation is where most real cloud compromises are won or lost. In Google Cloud, an attacker rarely starts as an administrator. They start with one leaked key, one over-permissioned service account, or one exposed workload, and then chain permissions until they control the project. This guide walks through how privilege escalation actually works in Google Cloud, the specific IAM permissions and services attackers abuse, a practical methodology, and how defenders can find and close these paths before someone else does.
What is privilege escalation in Google Cloud?
Privilege escalation in Google Cloud is the process of turning a low-privileged identity into a higher-privileged one, usually by abusing IAM permissions that were granted too broadly. Unlike traditional systems where escalation often means a kernel exploit, GCP escalation is almost always a chain of configuration and identity weaknesses: a service account you can impersonate, a role you can grant yourself, or a resource you can modify to run code as a more powerful identity.
The core unit of access in GCP is the service account, and the core question an attacker asks is: from where I stand, which identity can I become, and what can that identity do? Answer that repeatedly and you have an escalation path.
Why Google Cloud IAM is a rich escalation target
Google Cloud IAM is powerful and granular, which is exactly why misconfigurations are so common. A few properties make it a frequent escalation surface:
- Service account impersonation. If your identity can generate tokens for a service account, you effectively become that service account. A single
iam.serviceAccounts.getAccessTokenoractAspermission on the right account can be game over. - Self-granting permissions. Permissions like
resourcemanager.projects.setIamPolicylet an identity rewrite the project IAM policy and grant itself Owner. - Compute and metadata. Attaching a powerful service account to a VM, then reading its token from the instance metadata service, is a classic path.
- Deploy-as identities. Cloud Functions, Cloud Run, Deployment Manager and other services run code under a service account. If you can deploy to them, you can run code as that identity.
Common GCP privilege escalation techniques
The following are the escalation primitives that show up again and again in real Google Cloud environments. Most are single dangerous permissions that, once found, hand an attacker a more powerful identity.
Service account token generation and impersonation
Permissions such as iam.serviceAccounts.getAccessToken, getOpenIdToken, or signJwt let you mint credentials for a target service account. If that account has broader rights than you, you have escalated. Impersonation is often the shortest path to Owner because service accounts are frequently over-privileged.
actAs on compute and serverless
The iam.serviceAccounts.actAs permission lets you attach a service account to a resource you create. Combined with the ability to create a VM, a Cloud Function, or a Cloud Run service, you can deploy code that runs as a powerful account and have it hand you its token.
Editing the project IAM policy
If you hold resourcemanager.projects.setIamPolicy (or the folder or organization equivalent), you can add a binding that grants your own identity roles/owner. This is the most direct escalation there is, and it is granted more often than it should be through custom roles that were never audited.
Abusing deployment and automation services
Deployment Manager historically ran as a highly privileged Google-managed service account, and being able to submit a deployment could execute actions as that identity. Similar logic applies to any automation service, CI/CD runner, or workflow that executes with a service account more powerful than the user who can trigger it.
Compute metadata and startup scripts
If you can modify a running instance, add an SSH key, or set a startup script, you can execute code on a VM and read the attached service account token from the metadata service. Editing instance metadata is a well-worn route from compute access to cloud credentials.
Default service accounts with primitive roles
Many GCP workloads run as a default service account that was granted a primitive role at project creation. The Compute Engine default service account, for example, historically receives the Editor role, and the App Engine, Cloud Build, and Cloud Functions default identities are similarly broad. Any workload running in that context, a compromised VM, container, build job, or function, inherits those permissions. Editor alone lets an attacker create and modify resources across the project, deploy code that runs as other identities, and pivot widely, and where a service runs as Owner the entire project is exposed. Reducing default service accounts to least privilege, or replacing them with narrowly scoped dedicated accounts, closes one of the most common escalation and blast-radius gaps in Google Cloud.
Custom role and permission sprawl
Custom roles are where dangerous permissions hide. A role built for one narrow task often accumulates permissions like setIamPolicy or actAs that turn it into an escalation primitive. Enumerating what your current identity can actually do is the first step of every real assessment.
A practical GCP privilege escalation methodology
A cloud penetration test of Google Cloud follows the same shape as a real intrusion:
- Enumerate your identity. Determine who you are and what you can do. List the roles and permissions on your user or service account, and the resources you can see.
- Map reachable identities. Find every service account you can impersonate, act as, or otherwise assume, and what those accounts can do in turn.
- Find escalation primitives. Look specifically for
setIamPolicy,actAs, token generation permissions, and deploy-as-service-account paths. - Chain to Owner. Execute the shortest path from your identity to project, folder, or organization control, then verify impact against real resources like Cloud Storage buckets and Secret Manager.
- Understand detection. Review what Cloud Audit Logs record about your actions so you can advise defenders precisely, which is what separates a useful report from a list of permissions.
Tools for GCP privilege escalation testing
A tester's Google Cloud kit usually includes:
- The gcloud CLI and the underlying APIs, your primary interface once you hold credentials.
- GCP IAM privilege-escalation tooling that maps dangerous permissions and impersonation paths across a project, such as gcp-permissions-checker and gcpwn.
- Cross-cloud frameworks such as ScoutSuite and CloudFox for surveying configuration and identity relationships.
- Cloud Audit Logs on the defensive side, so you know what your actions look like to a SOC.
How defenders shut GCP escalation paths down
The same weaknesses attackers chain are the ones defenders should hunt for first:
- Audit for the high-risk permissions:
setIamPolicy,actAs, and service account token generation. Grant them narrowly and never in broad custom roles. - Apply least privilege to service accounts, and stop attaching powerful accounts to workloads that do not need them.
- Watch Cloud Audit Logs for IAM policy changes, new service account keys, and impersonation events.
- Test the environment adversarially. A configuration review tells you what is set; a privilege-escalation test tells you what an attacker can actually reach.
Learn GCP privilege escalation hands-on
You do not learn cloud escalation from a permissions table. You learn it by chaining real paths in a live project. Pwned Labs teaches this in Google Cloud accounts you are given to attack, from IAM enumeration to full project takeover. Work through hands-on Google Cloud security labs, then prove the full attack chain in a live environment with the Google Cloud Attack and Defense bootcamp and GCRTP certification. If your organization needs an expert team to test its own environment, see our GCP penetration testing services. For a wider view of the discipline, start with the GCP pentesting 101 guide.
Frequently asked questions
What is the most common privilege escalation path in Google Cloud?
Service account impersonation is the most common. If a low-privileged identity can generate tokens for, or act as, a more powerful service account, it inherits that account's permissions, and service accounts are frequently over-privileged.
Which GCP IAM permissions are the most dangerous?
The highest-risk permissions include resourcemanager.projects.setIamPolicy (rewrite the IAM policy and grant yourself Owner), iam.serviceAccounts.actAs (attach a service account to a resource you control), and the service account token permissions such as iam.serviceAccounts.getAccessToken.
Is GCP privilege escalation about exploits or misconfigurations?
Almost always misconfigurations. Google Cloud escalation is a chain of over-broad IAM grants and deploy-as-service-account paths, not memory-corruption exploits. That is why identity and configuration are the real perimeter.
How do I practice GCP privilege escalation safely and legally?
Use environments built for it. Hands-on labs and cyber ranges give you live, intentionally vulnerable Google Cloud projects to attack, which is how you build the pattern recognition that transfers to real engagements.
The fastest way to get good at this is to stop reading and start chaining real paths in a live project. Explore the hands-on cloud security labs and work a full Google Cloud escalation end to end.