A Google Cloud penetration test scope is defined by the resource hierarchy, not a list of servers. What belongs in a GCP penetration testing scope is the organization, folders, and projects that own your workloads, the IAM policies and service accounts that grant access across them, the Google Kubernetes Engine (GKE) clusters and their Workload Identity bindings, the Google Workspace tenant that anchors your identities, and the public web apps and APIs that front all of it. Google makes this test easy to start: you are not required to contact Google before assessing the security of your own Cloud Platform infrastructure, per the Google Cloud penetration testing policy. You only need to stay inside your own projects and honor the Acceptable Use Policy.
The reason a generic AWS guide leaves gaps is structural. GCP does not organize workloads the way AWS does, and its identity model is genuinely different. An AWS-shaped scope that lists VPCs, EC2, S3, and IAM users maps poorly onto a platform where the project is the unit of ownership, where a service account is a first-class identity you can impersonate, and where a single Workspace setting can reach across every project you own. This guide gives you a GCP-native scope map and an attack-path checklist so the engagement covers the surface that is actually there.
TL;DR: what to put in scope for a GCP penetration test
Unit of scope (resource hierarchy): name the organization, folders, and projects under test, because IAM policy is inherited down the tree and the project is the base organizing entity (Google Cloud resource hierarchy).
Identity surface (service accounts): include service account impersonation paths, since a principal with
iam.serviceAccounts.getAccessTokencan act as a higher-privileged account (Google Cloud IAM).Least-privilege enforcement (IAM Conditions): test whether conditional role bindings actually constrain access, or whether the condition is trivially satisfied (IAM Conditions).
Container surface (GKE): scope Workload Identity, the node metadata server, private-cluster and control-plane exposure, and node service-account permissions (GKE hardening guide).
Identity blast radius (Workspace): review domain-wide delegation, which lets a service account act across your entire Google Workspace tenant (Workspace domain-wide delegation).
Rules of engagement (Google policy): no advance notice is required to test your own projects; testing must not touch other customers (Google Cloud pentest policy).
Web and API front door (human plus agent): the public application and API layer is the one part of a GCP estate an autonomous web-app agent can carry, while identity, GKE, and Workspace stay human-led.
Why a GCP scope is not an AWS scope with the names swapped
The cost of getting cloud scope wrong is not abstract. The IBM Cost of a Data Breach 2024 report put the global average breach at US$4.88M, and cloud misconfiguration remains one of the common vectors it tracks. The Verizon 2025 Data Breach Investigations Report found the human element present in 60 percent of breaches, and misconfigured cloud access is one of the ways that plays out. A penetration test that inherits the wrong platform model tests the wrong things and misses the misconfigurations that matter.
Three structural differences drive the GCP-native surface:
The project is the unit of ownership. Google Cloud organizes everything into a tree: an organization at the root, optional folders, then projects, then the service resources inside them. Every resource except the root has exactly one parent, and access policies applied high in the tree are inherited by every resource below, per the resource hierarchy documentation. Scope is therefore a set of hierarchy nodes, not a set of IP ranges.
Service accounts are impersonatable identities. In GCP a service account is a principal you can authenticate as. That makes identity, not the network, the primary lateral-movement medium.
Google Workspace sits underneath it all. The same identity fabric that runs Gmail and Drive anchors Cloud IAM. Settings like domain-wide delegation cross the boundary between Cloud and Workspace in a way an AWS scope has no reason to look for.
The GCP-native scope map
Use this six-layer map to define what the test covers. It mirrors how a Google Cloud estate is actually built, from the public edge down to the identity fabric. For cross-cloud teams, our AWS SOC 2 scope guide and Azure Entra ID scope guide cover the equivalent layers on the other two platforms.
Layer 1: Public edge and exposed services
Cloud Load Balancing, Cloud CDN, Cloud Run and Cloud Functions endpoints, App Engine, API Gateway, and anything with a public IP or public URL. This is the classic external surface: exposed admin panels, unauthenticated endpoints, and services that should have been behind Identity-Aware Proxy but are not.
Layer 2: Authenticated app and API
The web applications and APIs your users log into. This is where broken authorization, IDOR, tenant-isolation failures, and business-logic abuse live, and it is the one layer of a GCP estate that an autonomous web application penetration testing agent can carry end to end. Stingrai's Snipe agent hunts exactly these complex, high-impact classes on the app and API that front your GCP backend, while the cloud-native layers below stay human-led.
Layer 3: IAM, service accounts, and impersonation
This is the layer an AWS guide misses most badly. Scope should include:
Service account inventory: default versus user-managed accounts, and which have exported JSON keys.
Impersonation paths: who holds
roles/iam.serviceAccountTokenCreatororroles/iam.serviceAccountUser, because those permissions let a principal mint tokens for another account and inherit its access, per the IAM impersonation reference.Primitive and over-broad roles: legacy Owner, Editor, and Viewer grants, and custom roles that quietly aggregate dangerous permissions.
IAM Conditions: whether conditional bindings genuinely constrain access. Conditions use Common Expression Language over resource, request, and principal attributes, per the IAM Conditions overview, and a poorly written condition can read as a control while granting access in practice. Our cloud IAM penetration testing guide goes deeper on proving these paths.
Layer 4: GKE and container workloads
Google Kubernetes Engine is a scope in its own right. Anchor it to Google's cluster hardening guidance and test:
Workload Identity Federation bindings, which are Google's recommended way for pods to authenticate to Cloud APIs, and whether a compromised pod can reach a service account it should not.
Node metadata server exposure, including any legacy metadata endpoints a pod could query to steal node credentials.
Private cluster and control-plane access, authorized networks, and whether the API server is reachable from the internet.
Node service-account permissions, since a node running with a broad default account hands that scope to every workload on it.
Legacy authentication, confirming ABAC is disabled and the insecure kubelet read-only port is not exposed.
Scoping and cost for the container layer are covered in our GKE and Kubernetes pentest guide.
Layer 5: Google Workspace and identity fabric
Because Cloud IAM rides on the same identity platform as Workspace, the tenant is in scope for any serious GCP assessment. The highest-value item is domain-wide delegation, which lets a service account impersonate users across the entire Workspace domain, per Google's delegation documentation. A single over-scoped delegation is a tenant-wide compromise waiting to happen. Also review super-admin exposure, OAuth app grants, and service-account keys that touch Workspace scopes.
Layer 6: Storage, data, and networking
Cloud Storage bucket IAM and ACLs, BigQuery dataset access, Cloud SQL exposure, Secret Manager permissions, VPC firewall rules, VPC Service Controls perimeters, and Shared VPC boundaries. This is where the resource hierarchy pays off or fails: a bucket policy inherited from a folder can quietly widen access far beyond what a single project view suggests.
The GCP attack-path checklist
Scope is not just a list of assets. It is the set of paths a tester is authorized to chain. These are the GCP-native chains to include in the rules of engagement.
Impersonation escalation: low-privilege principal, then
serviceAccountTokenCreatoron a higher-privileged account, then that account's access to data or admin APIs.Metadata to credentials: compromised web app or pod, then query the metadata server, then reuse the node or instance service-account token.
Key sprawl: an exported service-account key found in code, CI logs, or a bucket, then direct API access with no user context.
Condition bypass: an IAM Condition that looks restrictive but evaluates true under normal request attributes, so the binding grants access anyway.
Cross-project pivot: access in one project, then a shared service account, folder-level grant, or Shared VPC that reaches a second project.
Workspace crossover: a Cloud service account with domain-wide delegation, then impersonation of Workspace users and their data.
What Google's pentest policy does and does not require
Google's rules of engagement are refreshingly light, which is exactly why scoping discipline falls to you.
No advance notice. You do not have to tell Google before testing your own Cloud Platform infrastructure, per the penetration testing policy.
Stay in your own projects. Testing must only affect resources you own. Do not touch other customers.
Follow the Acceptable Use Policy and Terms of Service. These bound what you can do, regardless of the pentest.
Report platform bugs responsibly. If you find a vulnerability in Google's own platform rather than your configuration, report it through the Vulnerability Reward Program instead of exploiting it.
Because the platform does not force an approval gate, the engagement contract carries the load: define which projects and folders are in scope, which attack paths are authorized, what the blast-radius limits are, and whether production is live or a staged mirror is used.
What this means for defenders
A GCP penetration test earns its keep when the scope reflects Google's model instead of a borrowed one. Practically, that means:
Scope the hierarchy first. Name the org, folders, and projects, and confirm the tester will follow inherited IAM policy, not just per-project views.
Treat identity as the primary target. Fund the time to map impersonation and delegation paths. This is where real GCP compromises happen.
Split human-led from agent-led work deliberately. Identity, GKE, Workspace, and network segmentation are human-led. The public app and API front door is where an autonomous agent adds continuous coverage, so pair a human-led cloud assessment with continuous PTaaS on the applications that face the internet.
Use the results as compliance evidence. A scoped, severity-rated GCP pentest with a retest supports your SOC 2, ISO 27001, and PCI DSS programs with concrete evidence of control testing.
Go adversarial when maturity allows. Once the basics hold, a red team engagement can chain these GCP-native paths the way a real intruder would.
Stingrai is a CREST-accredited penetration testing provider, and GCP, GKE, Workspace, and IAM testing is delivered by senior human pentesters, with Snipe carrying the web app and API layer that fronts your cloud. For scope and pricing tailored to your project estate, see Stingrai pricing.
Frequently asked questions
What should be in scope for a Google Cloud (GCP) penetration test?
A GCP penetration test should scope the resource hierarchy first: the organization, folders, and projects that own your workloads, since IAM policy is inherited down that tree (Google Cloud). Then add the identity surface (service accounts and impersonation paths), IAM Conditions, GKE clusters and Workload Identity, the Google Workspace tenant, storage and networking, and the public web apps and APIs that front the estate.
Do I need permission from Google to run a penetration test on GCP?
No. Google does not require you to contact it before testing the security of your own Cloud Platform infrastructure, per the Google Cloud penetration testing policy. You must keep the test inside your own projects, follow the Acceptable Use Policy and Terms of Service, and avoid affecting other customers.
Why can I not just reuse my AWS penetration test scope for GCP?
Because the platforms model workloads and identity differently. In GCP the project is the unit of ownership and IAM policy is inherited through the org, folder, and project tree, while service accounts are impersonatable identities and Google Workspace anchors the same identity fabric. An AWS-shaped scope that lists VPCs, EC2, and IAM users misses impersonation, IAM Conditions, GKE Workload Identity, and Workspace domain-wide delegation.
What are the most important GCP IAM attack paths to test?
Service account impersonation is the headline path: a principal holding iam.serviceAccounts.getAccessToken can act as a higher-privileged account and inherit its access (Google Cloud IAM). Close behind are exported service-account keys, over-broad primitive roles, IAM Conditions that fail to constrain access, cross-project pivots via Shared VPC or shared accounts, and Workspace domain-wide delegation.
How is GKE penetration testing different from generic Kubernetes testing?
GKE testing adds Google-specific controls on top of standard Kubernetes work. Google's hardening guidance points to Workload Identity Federation, node metadata-server protection, private clusters and control-plane authorized networks, least-privilege node service accounts, and disabling legacy ABAC and the insecure kubelet read-only port. A GKE pentest confirms a compromised pod cannot reach cloud credentials it should not have.
What are IAM Conditions and why do they matter for scope?
IAM Conditions add attribute-based access control to role bindings using Common Expression Language over resource, request, and principal attributes (Google Cloud). They matter because a condition can look like a strong control while granting access in practice, so a GCP pentest should test whether each conditional binding actually restricts access or is trivially satisfied.
Does a GCP penetration test help with SOC 2 or ISO 27001?
Yes. A scoped, severity-rated GCP penetration test with a documented retest produces evidence of control testing that supports SOC 2, ISO 27001, and PCI DSS programs. The pentest demonstrates that vulnerabilities were found, rated, and remediated, which is the kind of artifact auditors look for.
Can an AI agent test my whole GCP environment?
No. Identity, GKE, Workspace, and network segmentation on GCP are human-led work, because they require reasoning about the resource hierarchy and trust relationships. An autonomous web-app agent like Stingrai's Snipe is the right tool for the public application and API layer that fronts your GCP backend, where it hunts complex authorization and business-logic flaws continuously, while senior pentesters carry the cloud-native layers.
References
Google Cloud. Penetration Testing (Cloud Platform FAQ). https://support.google.com/cloud/answer/6262505. States that customers are not required to contact Google before testing their own infrastructure, and must stay within their own projects and the Acceptable Use Policy.
Google Cloud. Resource hierarchy. https://docs.cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy. Defines the organization, folder, project, and resource tree and how IAM policy is inherited down the hierarchy.
Google Cloud. Service account impersonation. https://docs.cloud.google.com/iam/docs/service-account-impersonation. Explains how a principal with
iam.serviceAccounts.getAccessTokenauthenticates as a service account to gain its permissions.Google Cloud. IAM Conditions overview. https://docs.cloud.google.com/iam/docs/conditions-overview. Documents attribute-based access control on role bindings using Common Expression Language.
Google Cloud. Harden your cluster's security (GKE). https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster. Covers Workload Identity Federation, node metadata protection, private clusters, least-privilege node service accounts, and disabling legacy ABAC.
Google Workspace. Control API access with domain-wide delegation. https://support.google.com/a/answer/162106. Describes how a service account can be granted authority to act across users in a Workspace domain.
Verizon. 2025 Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/. Analyzes over 22,000 incidents and 12,000 confirmed breaches and reports the human element present in 60 percent of breaches.
IBM. Cost of a Data Breach Report 2024. https://www.ibm.com/reports/data-breach. Reports a global average breach cost of US$4.88M and tracks cloud misconfiguration as a common attack vector.
