GCP_CAN_DEPLOY_INFRA

Summary

FSProtect ACL Alias

GCP_CAN_DEPLOY_INFRA

GCP Alias

Compute Execution & Pipeline Pivots

Affected Object Types

Projects

Exploitation Certainty

Certain

Granting Roles

roles/deploymentmanager.admin, roles/deploymentmanager.editor

Description

GCP_CAN_DEPLOY_INFRA indicates that an identity can create and manage Deployment Manager deployments. Deployment Manager is GCP's infrastructure-as-code service (similar to Terraform or CloudFormation). Critically, Deployment Manager executes deployments using the Google APIs Service Agent ([PROJECT_NUMBER]@cloudservices.gserviceaccount.com), which is automatically granted roles/editor on the project.

An attacker with Deployment Manager permissions can define a deployment that provisions a VM or other resource with malicious configuration, all executed as the Google APIs SA. This SA has broad project-level write access and its token can be extracted from the provisioned resources.

Key abuse scenarios:

  • Deploy a VM via Deployment Manager (executed as Google APIs SA) → the SA has editor rights → extract SA token or abuse provisioned resources.

  • Deploy a Cloud Function with a custom SA → extract token from the function's execution environment.

  • Use Deployment Manager to create IAM bindings or service account keys as the Google APIs SA.

Identification

gcloud CLI

GCP Console

  1. Open GCP ConsoleDeployment Manager → review all existing deployments.

  2. Check IAM & AdminIAM for principals with Deployment Manager Admin or Deployment Manager Editor.

  3. Review the Google APIs SA ([PROJECT_NUMBER]@cloudservices.gserviceaccount.com) permissions.

Exploitation

gcloud CLI

Alternatively, SSH into the provisioned VM and extract the token interactively:

Compound path: GCP_CAN_DEPLOY_INFRA → deploy VM via Google APIs SA (roles/editor) → extract Compute Engine default SA token from metadata server → use token to create additional SA keys, modify IAM bindings, or impersonate higher-privilege SAs.

Mitigation

  1. Restrict roles/deploymentmanager.editor to a dedicated automation SA, never human users in production.

  2. Remove or restrict the Google APIs SA ([PROJECT_NUMBER]@cloudservices.gserviceaccount.com) permissions — the default roles/editor is too broad; use a custom minimal role if Deployment Manager is required.

  3. Prefer Terraform with a purpose-specific SA over Deployment Manager to avoid the overly privileged Google APIs SA.

  4. Audit all deployments for unexpected resource types or startup scripts.

  5. Enable deployment approval workflows before Deployment Manager can create or modify resources in production.

Detection

Log Type
Method
Key Fields

Admin Activity

insert (deploymentmanager)

resource.type=deployment, deployment creation

Admin Activity

*compute.instances.insert by Google APIs SA

VM created by Deployment Manager

Alert on:

  • Deployment creation by non-standard identities.

  • Deployments that provision compute instances.

  • Google APIs SA creating resources outside of known infrastructure pipelines.

References

  • https://cloud.google.com/deployment-manager/docs/access-control

Last updated

Was this helpful?