GCP privilege escalation is a permission problem: a single dangerous permission turns a limited member into project or organization owner. The catalog below is grounded in the Rhino Security Labs method list and the GCP-IAM-Privilege-Escalation project, grouped by the primitive each path abuses.

The paths#

• setIamPolicy: grant yourself any role at a resource, project, folder, or organization you can administer.
• Custom role update: add permissions to a custom role you already hold with iam.roles.update.
• Org policy: loosen organization-policy constraints with orgpolicy.policy.set to unlock other escalations.
• Metadata startup script: run code on an existing instance by writing compute.instances.setMetadata or an SSH key.
• actAs deployment: iam.serviceAccounts.actAs plus a resource-create verb to deploy code that runs as a privileged service account.

Choosing a path#

The most direct path is setIamPolicy if you hold it: it grants Owner in one call. Where you only hold actAs plus a deploy permission, pick the cheapest resource to create (a function or a Cloud Build is faster and quieter than a VM). Service-account impersonation primitives (getAccessToken, key creation) live under service account impersonation and often chain after one of these paths.

References#

• Rhino Security Labs: GCP privilege escalation (part 1)
• GCP IAM privilege escalation (Rhino repo)
• HackTricks Cloud: GCP privilege escalation