What breaks when a default cloud service account has broad project permissions and full API access in Google Cloud?

A compromised VM can become a launch point for lateral movement across every instance in the same project. When the default service account still has Editor privileges and the instance has full cloud API access, an attacker can enumerate resources, use cloud APIs, and pivot to other machines. The control failure is not the initial compromise, but the combination of excessive permissions and overly broad access scope.

Why the default service account becomes the blast-radius problem

The core issue is not that a VM was compromised. It is that the VM inherited a cloud identity with more authority than the workload needed. In Google Cloud, a default service account with broad project permissions can turn one host into a project-wide control point, because the attacker can use the VM’s own access to query resources, call APIs, and reach other assets that trust the same project boundary.

That changes the incident from a single-machine compromise into an authorization failure. Once the default account still has broad rights, the attacker does not need to break more systems to keep moving. They can use legitimate cloud APIs to discover what exists, what can be touched, and where the next useful access path lives.

How broad API access amplifies lateral movement

Full API access makes the compromise much more practical because it gives the attacker programmatic visibility and action at cloud speed. Instead of guessing at the environment from inside one VM, they can enumerate compute, storage, IAM-related resources, and other project-scoped services. That is why overbroad service account permissions are so dangerous: the same credential used for ordinary workload calls becomes a pivot mechanism once the workload is owned.

In practice, the attacker’s leverage comes from the combination of scope and privilege. If the VM can reach the metadata service and the service account can act across the project, the compromised host becomes a trusted API client. That trust is exactly what Service Account Security Guide and Cloud Workload Identity Guide are meant to reduce: the goal is to narrow what the workload can do, and to keep cloud access tied to the minimum identity needed for the job.

What breaks first in the project boundary

Once the default account has Editor-like rights, the project boundary stops behaving like a useful containment line. Resource discovery becomes trivial, privilege expansion becomes easier, and additional compromise options appear wherever the same project permissions can reach. If the project contains multiple machines, service endpoints, or automation paths, one compromised instance can be enough to touch them all.

That is why this pattern is so often described as lateral movement rather than simple post-compromise access. The attacker is not limited to the original VM. They can use the cloud control plane, inspect attached resources, and look for shared trust, exposed secrets, or other workloads that inherit the same overbroad assumptions. Kubernetes NHI Security Guide is a useful analogue here because it shows the same failure mode in another environment: a default identity with too much scope makes a single foothold much more dangerous than the compromise itself.

Risk and Threat Considerations

The main risk is blast-radius expansion. A compromise that should have been isolated to one VM can become project-wide exposure when the workload identity is overprivileged and broadly API-enabled. That creates a clear attacker incentive: use the compromised host as a legitimate API client, then move into discovery, persistence, or secondary compromise from inside the trust boundary.

Failure mechanism: The instance metadata-issued credential remains valid and powerful enough to enumerate and act on project resources, so the attacker can pivot through sanctioned cloud APIs instead of needing a new exploit.

Impact: Other instances, services, and project-scoped resources become reachable from the compromised VM, which can lead to broader access, faster privilege abuse, and harder-to-contain incident response.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Broad project permissions are the core failure in this cloud service account case.
	NHI-10 — Human Use of NHI	Default service accounts should not become general-purpose access paths for broad project activity.
Recommendation — Reduce workload roles to the minimum API actions the VM actually needs. Keep workload identities non-interactive and tightly bounded to machine use.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Excessive project permissions are the mechanism that expands a single VM compromise.
	IA-5 — Authenticator Management	Service account credentials and tokens must be managed so they cannot be reused broadly after compromise.
Recommendation — Restrict the account to the smallest set of permissions needed for the workload. Rotate and tightly govern credentials or tokens that can authorize cloud API calls.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Cloud workload access scope and project permissions are directly an IAM control issue.
Recommendation — Map each workload to a distinct identity and revoke unnecessary project-wide rights.
OWASP API Security Top 10	API5 — Broken Function Level Authorization	Full API access lets an attacker invoke functions beyond the workload’s legitimate authority.
	API9 — Improper Inventory Management	The attacker’s first step is project-wide resource discovery through the cloud API surface.
Recommendation — Enforce function-level authorization so compromised clients cannot call privileged operations. Maintain an accurate inventory of exposed API-capable resources and access paths.

Practitioner Guidance

What to verify: Check whether the default service account is still attached, what effective roles it has, and whether the workload truly needs full API access. If the answer is “no” to either, treat the configuration as an exposure problem rather than a convenience choice.

Decision rule: If a workload can be broken without losing the ability to run, remove default project-wide permissions first and then restore only the specific calls the application needs. If you cannot name the required API operations, the permission set is already too broad.

Practitioner takeaway: The real control is not whether the VM is hardened enough to prevent compromise, but whether a compromise can still be contained when the workload’s own identity has very limited reach.