A Google Cloud project inventory does not establish what a compromised Compute Engine workload can reach. This article explains how verified metadata, the attached service account, project scope, runtime identities, API boundaries, sensitive-material handling, and rollback combine into defensible attack paths.
Compute Engine is Google Cloud's virtual machine service. An inventory collected with an administrator account answers an administrator's question; it does not show what a compromised Compute Engine workload can reach through its attached service account.
Pentest Copilot is an internal assessment system. It starts with the VM's attached service account, obtained through the Google metadata server. The metadata response must identify the approved project. Discovery then preserves the resource and runtime-identity relationships needed to distinguish a permission from an attack path.
| Security question | Discovery rule | Why it matters |
|---|---|---|
| Which identity belongs to the VM? | Resolve the attached service account through verified metadata | Avoids substituting a developer session |
| Which project is in scope? | Match the metadata project to the approved project | Prevents configuration from selecting an unrelated project |
| What does a permission control? | Connect IAM bindings to exact resources and runtime identities | Broad-looking IAM does not prove workload control |
| What remains unknown? | Keep denied, disabled, absent, and failed API results distinct | Prevents partial visibility from becoming false assurance |
The four paths below explain the method:
| Layer | What is established |
|---|---|
| Machine identity | Service account attached to the Compute Engine VM |
| Metadata trust | Required Google metadata request and response behavior |
| Scope | One approved Google Cloud project |
| Relationship map | IAM, compute, serverless, GKE, build, data, messaging, networking, and keys remain connected |
| Authorization boundary | Disabled APIs, denials, absent resources, and other failures remain separate states |
| Active proof | Exact targets and approved attack categories |
| Sensitive material | Assertions, tokens, service-account keys, and HMAC secrets are not published as evidence |
| Recovery | Reversible IAM and workload changes return to the baseline |
Compute Engine exposes project and service-account information through its metadata server. Google requires the Metadata-Flavor: Google request header and documents the available metadata paths in View and query VM metadata.
The assessment reads the project identifier and attached service-account identity from that source. It also verifies that metadata requests have not been redirected to a different endpoint. The detected project must match the approved assessment project before any service enumeration begins.
The service account receives short-lived access tokens from the metadata server. Google documents this workload-authentication pattern in Authenticate workloads to Google Cloud APIs. Using those tokens preserves the permissions of the workload itself instead of importing the broader authority of a human administrator.
Impact: every resource and permission in the result is tied to the service account running on the VM and the project that hosts it.
Consider an IAM binding that allows a principal to update one Cloud Run service. The binding does not explain impact on its own. A principal that can update a Cloud Run service is only as powerful as the exact service it can change, the runtime service account that service uses, and the resources that runtime can access.
| Google Cloud object | Relationship that matters | Candidate path |
|---|---|---|
| Compute Engine VM | Runs as an attached service account | Workload compromise becomes API access |
| IAM binding | Grants a role to a principal at a scope | Identity reaches a specific action |
| Cloud Run service or Function | Executes as a runtime service account | Code control becomes identity control |
| GKE cluster | Connects IAM, Kubernetes authorization, nodes, and workloads | Cloud access becomes cluster or pod access |
| Cloud Build trigger | Starts a build under an execution identity | Source or trigger control becomes build execution |
| Storage, BigQuery, or Cloud SQL | Holds protected data behind service-specific authorization | API access becomes data impact |
| Pub/Sub or Eventarc | Connects publishers, events, and workloads | Message control reaches downstream execution |
| Cloud KMS key | Protects data or signing operations | Key use or administration affects another resource |
These edges prevent two common errors. First, a project-level role is not treated as control of every resource when conditions or service boundaries narrow it. Second, permission to change a workload is not reported as privilege escalation until the destination runtime identity and an approved action are known.
Impact: the assessment describes the complete transition-service account to permission, permission to resource, resource to runtime identity, and runtime identity to impact.
Google Cloud discovery crosses many APIs, so an empty result needs context. It can mean the service is disabled, the service account lacks permission, or the project contains no matching resource. A separate request failure leaves visibility unknown for another reason.
| Result | Meaning |
|---|---|
| API disabled | The service is not currently available through that project API |
| Permission denied | Resources may exist, but this identity cannot enumerate or access them |
| Empty successful response | The approved query found no matching object |
| Other error | Visibility is unknown until the failure is resolved |
Collapsing those states into an empty list would make a partially visible project appear clean. Preserving the boundary also improves remediation: enabling an API, granting read access, removing a dangerous role, and fixing a malformed request are different actions.
Discovery can continue after a service boundary only when the missing relationship cannot change the meaning of later results. A denied, disabled, or malformed response never supplies an edge for a later attack path.
Impact: defenders can see both the discovered path and the parts of the project that the workload identity could not prove safe.
The strongest Google Cloud paths often involve sensitive authentication material that must never become report content. Workload Identity Federation assertions, access tokens, temporary service-account keys, and storage-compatible HMAC secrets should remain inside the controlled validation boundary.
| Candidate path | Bounded proof | Safe evidence |
|---|---|---|
| Service-account impersonation | Impersonate one exact target and perform one approved read | Source and target identities plus the result |
| Workload Identity Federation | Validate issuer and audience, exchange the assertion, impersonate one target | Provider, audience, target identity, and accepted action |
| Cloud Run or Function control | Deploy one controlled revision and verify the runtime principal | Target, runtime identity, action, and restoration |
| Disk access | Snapshot an owned disk and attach a read-only clone | Bounded marker read and cleanup result |
| Temporary key path | Use one ephemeral key for a bounded action | Key identifier, expected identity, action, and deletion |
For workload replacement, the original image and service configuration form the recovery baseline. For disk validation, the reader, clone, and snapshot are removed. For temporary identity material, deletion is verified after the bounded action.
Token issuance alone proves authentication, not privilege escalation. The intended target action must also succeed before the transition is reported as a stronger identity path.
Google Workspace remains a separate boundary. Project IAM does not prove access to Gmail, Drive, Calendar, or Chat. Workspace testing requires an approved domain, delegated user, administrator-approved scopes, and protected test data.
Impact: a usable identity transition is verified without placing reusable assertions, tokens, or key material into the relationship map, article, or evidence.
A project-scoped assessment cannot establish what exists in other projects, folders, or the organization. A denied API remains unknown rather than empty. IAM analysis can identify a plausible transition, but runtime identity and service behavior still have to be verified where active proof is approved. Workspace access is not inferred from Google Cloud access.
The useful outcome is not the largest possible inventory. It is a project-scoped map in which the starting service account, resource relationships, authorization boundaries, active proof, and recovery all refer to the same path. When those pieces do not line up, the uncertainty stays visible.
