GCP penetration testing assesses your Google Cloud configuration and identities under the shared responsibility model. Google requires no prior approval or notification to test your own projects — you must simply comply with the Acceptable Use Policy and only affect your own projects. GCP's security model centres on service accounts and the resource hierarchy, so the dominant attack path is service-account privilege escalation and impersonation (actAs, getAccessToken, signJwt, key creation, setIamPolicy), alongside Compute metadata credential theft, misconfigured GCS buckets, and over-permissive primitive roles. We test manually, map findings to CIS Google Cloud Foundations Benchmark, and include a retest.
// 01 What is GCP penetration testing?
GCP penetration testing is a manual assessment of your Google Cloud environment — your projects, service accounts, IAM and resources — to find how an attacker could escalate access or reach your data. GCP's distinguishing feature is its service-account model and its resource hierarchy (organisation → folder → project), where IAM policies inherit down the tree. The result is that GCP attacks are overwhelmingly identity attacks: the ability to impersonate a more privileged service account is often worth more than any single misconfiguration.
As with every cloud, scope follows the shared responsibility model. We test security in the cloud — your IAM, service accounts, Compute, storage and workloads — not Google's underlying infrastructure, which is off-limits and out of scope.
// 02 GCP's testing policy: no approval needed
Google's position is refreshingly simple: you do not need to contact Google to penetration test your own Cloud Platform infrastructure. There is no form and no notification. The conditions are that you comply with the Google Cloud Acceptable Use Policy and Terms of Service, and that your testing only affects your own projects — not other customers' applications or the shared platform. Vulnerabilities you find in Google's own services should be reported through Google's Vulnerability Reward Program.
| GCP rule | Detail |
|---|---|
| Approval / notification | Not required for your own projects |
| Acceptable Use Policy | Must comply with the AUP and Terms of Service |
| Scope | Only your own projects — not other customers |
| DoS / DDoS | Prohibited |
| Shared / multi-tenant infrastructure | Prohibited to test |
// 03 What we test in a GCP environment
Service-account escalation
Dangerous permissions (actAs, getAccessToken, signJwt, key creation, setIamPolicy) and impersonation chains that reach more privileged accounts.
Metadata & instances
SSRF to the Compute metadata server for service-account tokens, and default over-scoped service accounts on VMs (the broad cloud-platform scope).
Storage exposure
Public buckets granted to allUsers or allAuthenticatedUsers, uniform vs fine-grained ACL misconfiguration, and data exfiltration.
Roles & cross-project
Primitive roles (Owner/Editor) instead of least privilege, cross-project trust, org-policy gaps, and secrets in service-account keys.
// 04 Common GCP findings
Service-account impersonation to escalation
A principal with actAs or getAccessToken on a privileged service account impersonates it and inherits its access, reaching far beyond its own permissions.
Compute metadata token theft
An application SSRF reaches the metadata server and steals the instance's service-account token — especially damaging when the VM runs a default, over-scoped account.
Public GCS bucket
A bucket granted to allUsers or allAuthenticatedUsers exposing sensitive data to anyone.
Primitive roles instead of least privilege
Broad Owner or Editor grants (including on the default service account) that give far more access than needed.
// 05 Standards we test against
CIS Google Cloud Platform Foundation Benchmark: the config baseline for IAM, service accounts, GCS, Compute, logging and more.
Google Cloud security best practices / Security Command Center: Google's own guidance.
MITRE ATT&CK Cloud (identity techniques): findings mapped to attacker techniques for your defenders.
Compliance: mapped to PCI DSS, SOC 2, ISO 27001 and the GCC frameworks where relevant — see our requirements finder.
// 06 Frequently asked questions
Do I need Google's approval?
No. Google does not require you to contact them to test your own GCP infrastructure. Comply with the Acceptable Use Policy and only affect your own projects.
What does it cover?
Service-account privilege escalation and impersonation, over-permissive IAM, Compute metadata theft, GCS exposure, Cloud Functions/Run and cross-project trust — your configuration and identities.
Most common serious finding?
Service-account privilege escalation via actAs, getAccessToken, signJwt, key creation or setIamPolicy — and over-scoped default service accounts on Compute instances.
Can you test Google's infrastructure?
No — that's Google's responsibility. Testing must only affect your own projects; the shared platform is off-limits.
// 07 References
- Google Cloud Security FAQ (penetration testing) — no prior contact required; comply with the Acceptable Use Policy; own projects only; report via the Vulnerability Reward Program.
- CIS Google Cloud Platform Foundation Benchmark; Google Cloud security best practices; MITRE ATT&CK Cloud matrix.