Home

Published

- 11 min read

Unlocking the Kingdom: A CISO's Guide to GCP IAM Privilege Escalation

By William OGOU
gcp GCP privilege escalation GCP IAM security Cloud security misconfigurations Secure GCP IAM GCP attack vectors Service Account exploitation Cloud identity security
img of Unlocking the Kingdom: A CISO's Guide to GCP IAM Privilege Escalation

Google Cloud Platform (GCP) offers unparalleled power and flexibility for modern enterprises. At the heart of its security model lies Identity and Access Management (IAM), a sophisticated system designed to control who (identity) can do what (role/permissions) on which resources. However, the very granularity and power of GCP IAM, if misconfigured, can inadvertently create pathways for privilege escalation, turning seemingly innocuous permissions into keys to the kingdom.

This isn’t typically about exploiting vulnerabilities in GCP itself, but rather about attackers leveraging weaknesses in the configuration of your GCP environment. For CISOs, understanding these vectors is paramount to building a truly resilient cloud security posture. This blueprint aims to shed light on common GCP IAM privilege escalation methods and provide actionable mitigation strategies.

What Exactly is Privilege Escalation in GCP IAM?

In the context of GCP IAM, privilege escalation refers to an attacker gaining more permissions or access rights than they were initially assigned. This is often achieved by exploiting:

  • Overly Permissive Roles: Assigning roles with broader permissions than necessary for a user or service account.
  • Misconfigured Permissions: Specific individual permissions that, when combined or used in a particular way, allow an entity to grant itself more privileges.
  • Exploitable Service Account Configurations: Abusing the way service accounts are used by services like Compute Engine, Cloud Functions, or Deployment Manager.
  • Metadata Exposure: Sensitive information, like SSH keys, accessible through instance or project metadata.

It’s crucial to reiterate: these are usually not flaws in GCP’s underlying infrastructure but rather vulnerabilities introduced through user or administrative configuration choices.

Common GCP IAM Privilege Escalation Vectors: A CISO’s Watchlist

Let’s categorize and highlight some of the most impactful ones CISOs should be aware of:

1. Direct IAM Manipulation:

  • iam.roles.update: This permission allows a user to modify custom IAM roles. An attacker with this permission can add any other permission (including resourcemanager.projects.setIamPolicy or resourcemanager.organizations.setIamPolicy) to a role they control, effectively granting themselves project or even organization-level ownership.
  • iam.serviceAccounts.getAccessToken: Allows impersonation of a service account to generate a short-lived OAuth2 access token for it. If the target service account has higher privileges, this is a direct escalation path.
  • iam.serviceAccountKeys.create: Permits the creation of new, long-lived key pairs (credentials) for a service account. An attacker can create keys for a privileged service account and use them indefinitely.
  • iam.serviceAccounts.implicitDelegation: A more nuanced but powerful permission. If Service Account A has implicitDelegation on Service Account B, and Service Account B has getAccessToken permission on Service Account C, then Service Account A can effectively get an access token for Service Account C. This creates chains of trust that can be exploited.
  • iam.serviceAccounts.signBlob & iam.serviceAccounts.signJwt: These allow a user or service account to sign arbitrary data or JWTs using the Google-managed private key of a target service account. This can be used to impersonate the service account for various purposes, including generating access tokens.
  • iam.serviceAccounts.actAs (The “Impersonation” Powerhouse): This is one of the most critical permissions. It allows a principal to obtain credentials for a service account and perform actions as that service account. If a user can actAs a highly privileged service account, they inherit all its permissions. This is a cornerstone of many escalation techniques, especially when combined with service creation permissions.

2. Service-Specific Permissions with IAM Implications:

Many GCP services create or manage resources that operate with the permissions of an associated service account. If an attacker can control the creation or configuration of these resources, they can often leverage the service account’s privileges.

  • deploymentmanager.deployments.create: Deployment Manager allows infrastructure-as-code deployments. Crucially, resources specified in a deployment template are created using the permissions of the default Google APIs Service Account (<project-number>@cloudservices.gserviceaccount.com), which often has the highly privileged “Editor” role on the project. An attacker with this single permission can deploy resources (like a new VM) that run as this Editor SA, effectively taking control of the project.
  • cloudfunctions.functions.create / cloudfunctions.functions.update: Allows creating or updating Cloud Functions. Functions can be configured to run as a specific service account. If an attacker can deploy or modify a function to run as a privileged SA, they can execute arbitrary code with those privileges. The function can also access its own service account’s token via the metadata API.
  • compute.instances.create: Allows creation of Compute Engine VM instances. An attacker can create a new VM and attach a privileged service account to it. They can then SSH into the VM (if network paths allow) or use a startup script to exfiltrate the service account’s token from the metadata service.
  • run.services.create: Similar to Cloud Functions, allows creation of Cloud Run services that can be configured to run as a specific service account, providing an execution environment with that SA’s privileges.
  • cloudscheduler.jobs.create: Allows creating Cloud Scheduler cron jobs that can target HTTP endpoints. If the endpoint is a Google API, the job can be configured to authenticate as a specific service account, allowing the attacker to make API calls with that SA’s identity.

3. Non-IAM Permissions That Can Enable Escalation:

  • orgpolicy.policy.set: While not directly granting IAM permissions, this allows modification of Organization Policies. An attacker could disable policies that restrict certain actions (e.g., appengine.disableCodeDownload or policies restricting service account usage), thereby enabling other escalation paths.
  • storage.hmacKeys.create: Allows creation of HMAC keys for service accounts or users to interact with Cloud Storage using AWS S3-compatible APIs. If created for a privileged service account, these keys can be used to access GCS data with those privileges.
  • serviceusage.apiKeys.create / serviceusage.apiKeys.list: By default, API keys created in a project often have broad access. An attacker creating or listing API keys might find one with excessive permissions.

4. The Universal Risk: *.setIamPolicy Permissions:

Any permission that allows a user to set the IAM policy on a resource (e.g., resourcemanager.projects.setIamPolicy, resourcemanager.folders.setIamPolicy, cloudfunctions.functions.setIamPolicy, storage.buckets.setIamPolicy, etc.) is inherently a privilege escalation vector. With this, an attacker can simply grant themselves any desired role (like Owner or Editor) on that resource.

A Practical Example: Abusing Compute Instance IAM Misconfigurations

Concrete example of chaining misconfigurations:

  1. Initial Access: Attacker gains access to a service account (instance-mgmt-srv-acc) with no project-level roles.
  2. Enumerate Compute Instances: Finds an existing instance (process-instance).
  3. Instance Metadata Review: Discovers the instance is using the default Compute Engine service account (<project-number>[email protected]).
  4. Project IAM Check (for Default SA): Finds this default service account has the “Editor” role at the project level – a common, overly permissive default in older projects.
  5. Instance IAM Check: The initially compromised instance-mgmt-srv-acc is found to have roles/compute.instanceAdmin.v1 on process-instance. This role includes compute.instances.setMetadata.
  6. SSH Key Injection Attempt (Blocked by OAuth Scopes/Newer Protections): Even with setMetadata, directly modifying instance metadata to add an SSH key might be restricted if the instance-mgmt-srv-acc doesn’t have iam.serviceAccounts.actAs on the instance’s attached service account (the Editor SA). Also, OAuth scopes on the instance itself can further limit what its attached SA can do.
  7. Exploiting Project-Wide SSH Keys in Metadata: The attacker then checks project-level metadata and finds a public SSH key for a user named developer.
  8. Network Tag Manipulation for SSH Access: SSH access to the instance is initially blocked by firewall rules. The attacker, using their compute.instanceAdmin.v1 role on the instance (which includes compute.instances.setTags), adds the required network tag (e.g., “ssh”) to the instance.
  9. Successful SSH & Data Exfiltration: With the network tag applied and possessing the private key for the developer user (perhaps found elsewhere or the contrived part of a CTF), the attacker SSHes into the instance. The instance’s attached service account (the Editor SA) has devstorage.read_only OAuth scope by default, allowing the attacker (now on the instance) to use gsutil to list and download data from project storage buckets.

This example beautifully illustrates how initial limited access, combined with common misconfigurations (default Editor SA, ability to set tags, exposed SSH keys in project metadata), can lead to significant data access.

Detecting GCP IAM Privilege Escalation

  • Specialized Scanners: Tools like Rhino Security Labs’ PrivEscScanner (found in their GCP-IAM-Privilege-Escalation GitHub repo) are designed to enumerate members and permissions and automatically check for known privilege escalation paths.
  • Cloud Audit Logs & Security Command Center: Monitor Cloud Audit Logs for suspicious IAM policy changes (SetIamPolicy), service account key creation, role updates, and sensitive API calls. GCP’s Security Command Center can help surface misconfigurations and threats.
  • Regular IAM Reviews: Periodically audit IAM policies for overly permissive roles, stale accounts, and excessive use of primitive roles (Owner, Editor, Viewer).
  • Custom Alerts: Set up alerts for modifications to critical IAM policies or the use of high-privilege service accounts by unexpected principals.

Mitigation: The CISO’s Blueprint for a Hardened GCP Environment

  • Embrace the Principle of Least Privilege (PoLP): This is foundational. Grant only the necessary permissions required for a user or service to perform its intended function. Avoid primitive roles (Owner, Editor, Viewer) for service accounts; use granular, predefined, or custom roles.
  • Secure Service Accounts:
  • Don’t use the default Compute Engine service account with Editor role. If using default SAs, restrict their permissions significantly. Prefer user-managed service accounts with minimal, specific roles.
  • Limit iam.serviceAccounts.actAs: This permission should be granted very sparingly and only to trusted principals for specific, necessary impersonations.
  • Rotate service account keys regularly if user-managed keys are unavoidable. Prefer Google-managed keys where possible.
  • Restrict who can create service account keys (iam.serviceAccountKeys.create).
  • Control setIamPolicy Permissions: Drastically limit who can modify IAM policies at the organization, folder, and project levels. This is one of the most direct paths to full control.
  • Secure Instance and Project Metadata:
    • Disable metadata access for instances that don’t need it.
    • Never store private SSH keys or other sensitive secrets in metadata. Use Secret Manager.
    • Restrict who can set project-wide SSH keys. Prefer OS Login where appropriate.
  • Configure OAuth Scopes Carefully: For Compute Engine instances, ensure the attached service account has the narrowest possible OAuth scopes required for its tasks, even if the SA itself has broader IAM roles. Scopes act as a crucial secondary check.
  • Restrict Risky Service Permissions: Be extremely cautious when granting permissions like deploymentmanager.deployments.create, cloudfunctions.functions.create, or compute.instances.create if they can leverage highly privileged service accounts. Ensure that if these permissions are granted, the associated service accounts are tightly controlled.
  • Network Segmentation and Firewall Rules: Use VPC firewall rules and network tags to restrict network access between resources, limiting the blast radius if an instance is compromised.
  • Regular Audits and Automated Scanning: Continuously audit your IAM configurations using both GCP’s tools and third-party scanners. Integrate security checks into your CI/CD pipelines.
  • Disable Unused APIs and Services: Reduce the attack surface by disabling GCP APIs and services that are not in use within your projects.

Conclusion: Vigilance is the Key to GCP IAM Security

GCP IAM provides a powerful and flexible framework for managing access to cloud resources. However, its complexity means that misconfigurations can easily occur, opening doors for privilege escalation. By understanding the common attack vectors, leveraging specialized scanning tools, and adhering to a defense-in-depth strategy centered on the principle of least privilege, CISOs can significantly reduce the risk of IAM-based compromises. The journey to a secure cloud environment is continuous, requiring ongoing vigilance, regular audits, and a proactive approach to identifying and remediating misconfigurations before attackers can exploit them.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].

GCP IAM Privilege Escalation FAQ:

  • What is the most common way privilege escalation occurs in GCP IAM? It often occurs through overly permissive roles (like assigning “Editor” to service accounts by default), misconfigured iam.serviceAccounts.actAs permissions allowing impersonation of powerful service accounts, or any user/service having *.setIamPolicy permissions on critical resources.
  • Is using the default Compute Engine service account a security risk? Yes, if left with its default “Editor” role, it can be a significant risk. If this service account is compromised (e.g., via a vulnerable application on a VM using it), an attacker gains broad control over the project. It’s best practice to assign it minimal permissions or use dedicated, least-privilege service accounts for VMs.
  • How can deploymentmanager.deployments.create lead to privilege escalation? Deployments are often executed with the privileges of the default Google APIs Service Account (which might have the “Editor” role). If an attacker can create deployments, they can deploy resources that run as this privileged account, effectively inheriting its permissions.
  • What’s the best way to prevent GCP IAM privilege escalation? The principle of least privilege is paramount. Grant only the necessary permissions for any identity. Regularly audit IAM policies, restrict setIamPolicy and iam.serviceAccounts.actAs permissions, secure service account keys, use specific OAuth scopes, and employ automated tools to scan for misconfigurations.
  • Are these escalation methods flaws in GCP itself? Generally, no. They are usually a result of misconfigurations or overly permissive setups by users or administrators, rather than vulnerabilities in GCP’s underlying infrastructure or IAM service.

Relevant Resource List: