GCP Penetration Testing: Google's Rules and Real Attack Paths

Google Cloud compromises follow the same pattern as the other clouds: they run on identity. A service account with more rights than its job, a user-managed key in a repository, a permission that lets one identity impersonate another, or a metadata endpoint reachable from a vulnerable app. GCP penetration testing targets that identity and configuration layer, plus the storage, GKE workloads and services it controls. This guide covers Google’s rules for testing, what a test checks, an example attack path, and how to scope one. It is the Google Cloud companion to our AWS penetration testing and Azure penetration testing guides.

Google’s rules for testing your own projects

You do not need Google’s permission or a notification to test your own Google Cloud projects. Google’s Cloud Security FAQ states plainly: “If you plan to evaluate the security of your Cloud Platform infrastructure with penetration testing, you are not required to contact us” (Google Cloud Security FAQ). Two conditions apply. You must stay within the Acceptable Use Policy and Terms of Service, and your tests must “only affect your projects (and not other customers’ applications).”

The Acceptable Use Policy sets the outer boundary. It prohibits using the services to “gain unauthorized access to, disrupt, or impair the use of the Services,” to distribute destructive code, or “to test or reverse-engineer the Services in order to find limitations or vulnerabilities, or to evade filtering capabilities, except as expressly permitted in the Agreement.” In plain terms: test your own resources, never Google’s shared infrastructure or another tenant, and do not run denial-of-service or resource-exhaustion attacks against the platform. If a test turns up a vulnerability in Google’s own services, the FAQ asks you to report it through Google’s Vulnerability Reward Program.

Shared responsibility: what is yours to test

Google secures the infrastructure. You secure what you build on it: your IAM policies and service accounts, your Cloud Storage buckets, your Compute Engine and GKE workloads and the software on them, your secrets, your network configuration, and your data. Effectively everything worth testing in your organization sits on your side of the line. Google’s own compliance attestations cover its infrastructure, never your configuration of it, which is why running in Google Cloud moves a testing obligation rather than removing it.

Why IAM is the real GCP perimeter

Every Google Cloud resource is reached through an identity, and a valid token for the right identity works from anywhere. Network rules do not stand between a stolen credential and your projects; IAM does. Three things make GCP’s identity model its own discipline.

Basic roles are far too broad. Google’s basic roles (now Admin, Writer and Reader, alongside the legacy Owner, Editor and Viewer roles) “include thousands of permissions across all Google Cloud services,” and Google’s guidance is direct: “In production environments, do not grant basic roles unless there is no alternative” (Google Cloud, IAM roles overview). A test flags every basic-role grant on a production project as a starting point.

Default service accounts used to be Editor. Depending on organization policy, the Compute Engine default service account (PROJECT_NUMBER-compute@developer.gserviceaccount.com) can be granted the Editor role on the project automatically, which means any workload running as it inherits broad project control. Google strongly recommends disabling that automatic grant with the iam.automaticIamGrantsForDefaultServiceAccounts constraint, which is enforced by default for organizations created after May 3, 2024 (Google Cloud, service accounts). Older organizations often still carry the wide grant, so a test checks the actual bindings, not the age of the org.

Service account keys do not expire by default. Keys created and downloaded from IAM “don’t have an expiry time and stay valid until you delete them” unless you set an expiry, and Google lists credential leakage and privilege escalation among their main threats, recommending more secure alternatives such as attached service accounts and workload identity federation (Google Cloud, best practices for service account keys). An old key in a repository is often a credential with no clock on it.

What a GCP penetration test covers

IAM roles and bindings

Basic-role grants on production, custom roles that quietly bundle sensitive permissions, and identities that can change IAM policy through a setIamPolicy permission (an identity that can grant access can grant it to itself). The test reads the policy graph across the organization, folders and projects, because a binding inherited from a folder nobody looks at reaches every project beneath it.

Service accounts and impersonation

Service accounts are the workhorses of GCP and the main escalation path. The test maps which principals can impersonate a service account through iam.serviceAccounts.getAccessToken (the Service Account Token Creator role), sign tokens with signBlob or signJwt, or create keys with iam.serviceAccountKeys.create. It also maps who can attach a service account to a resource: the iam.serviceAccounts.actAs permission, held by the Service Account User role, is “required to attach a service account to a resource” (Google Cloud, attach service accounts), and whoever can attach an account can run code as it. Combined with a create permission such as compute.instances.create, cloudfunctions.functions.create or run.services.create, that becomes a documented privilege-escalation chain: launch a resource with a privileged service account attached, then read its token. Security researchers have published catalogues of these permission chains with working exploit scripts (Rhino Security Labs, GCP privilege escalation), and the test checks each one against your actual bindings.

The metadata server

Every Compute Engine instance can reach the metadata server at metadata.google.internal or 169.254.169.254, and it hands out OAuth2 access tokens for the attached service account. Requests must carry the Metadata-Flavor: Google header (Google Cloud, querying metadata). That makes any server-side request forgery (SSRF) flaw in an application on the instance a direct route to the instance’s cloud credentials. Testing an internet-facing app and testing the cloud around it belong in one conversation, which is why a web application test and a cloud test are usually scoped together.

Cloud Storage exposure

Buckets and objects opened to allUsers, which “represents anyone who is on the internet, including authenticated and unauthenticated users,” or to allAuthenticatedUsers, which “represents all service accounts and all users on the internet who have authenticated with a Google Account,” including personal Gmail accounts (Google Cloud, principals overview). The second one surprises teams who assumed “authenticated” meant “our organization.” The test also checks uniform bucket-level access, public access prevention, and HMAC keys that can be abused for data access.

GKE and workload identity

On Google Kubernetes Engine, the question is how a pod reaches Google Cloud APIs. Without Workload Identity Federation for GKE, pods fall back to the node’s service account, and if no account was chosen at node pool creation, that is the Compute Engine default service account. With it, GKE runs its own metadata server on every node, which intercepts credential requests from workloads and exchanges them for short-lived tokens tied to the Kubernetes identity. Google calls it, in most cases, “the recommended way to help secure and manage how your workloads that run on GKE access Google Cloud services” (Google Cloud, Workload Identity Federation for GKE). A test checks whether it is enabled, plus the cluster RBAC, exposed dashboards and container escape paths. When Kubernetes is the main concern, our Kubernetes penetration testing covers the cluster in depth.

Logging and detection

Whether the test would have been seen. Admin Activity and System Event audit logs “are always written; you can’t configure, exclude, or disable them,” but “except for BigQuery, Data Access audit logs are disabled by default” (Google Cloud, Cloud Audit Logs). A common finding is that the enumeration and data-access steps of an attack left no trace because Data Access logging was never turned on.

Example attack path: from one SSRF to other projects

This is how a report narrates a chain. Each step is a medium or low on its own; together they are critical.

1. An SSRF in a web app. A form on a Compute Engine instance fetches a URL the user supplies, with no allow-list.
2. The metadata server answers. The attacker points it at 169.254.169.254 with the Metadata-Flavor: Google header and reads an access token for the instance’s attached service account.
3. A service account broader than its job. That account still carries the legacy Editor role, so the token can read across the project.
4. A key to something bigger. In a storage bucket the account can read, an old user-managed service account key from a migration sits in a config file, and that identity has a role over other projects.

From one SSRF, the tester reaches broad control without touching Google’s infrastructure. In an authorized test the access is proven and the tester stops there, inside your own projects, which is also where Google’s rules keep the test. The fixes, in order: validate and allow-list the URL fetch, scope the instance’s service account to least privilege, move off user-managed keys to workload identity federation, and turn on Data Access audit logs so the next attempt is visible. A configuration scanner can flag the broad role in step 3 and perhaps the key in step 4 as separate items, but it cannot find the SSRF in step 1 or prove that the steps connect. Showing the chain is the value of the test.

Configuration review vs attack-path testing

The configuration review. With read-only access, every project is compared against the CIS Google Cloud Platform Foundation Benchmark, using Security Command Center findings and open-source tools such as Prowler and ScoutSuite to cover hundreds of settings quickly. The output is a list of settings that differ from the recommended value: public buckets, basic-role grants, disabled logging, keys past their rotation date.

The attack-path testing. The tester starts from a realistic foothold (a standard user, a developer’s identity, a leaked key or a compromised app) and works toward the data and the projects. Identity-graph analysis, the same discipline behind BloodHound on the Active Directory side, maps which principals can impersonate, attach or grant their way to which resources. The output is a set of proven chains, like the one above, ranked by what they reach. A Security Command Center findings export covers only the first part, and auditors can tell the difference. If what you need is a GCP security assessment of the configuration alone, without exploitation, our cloud security assessment is built for that.

How to scope a GCP penetration test

Have these ready and scoping takes one call:

1. Projects and structure: how many projects, and how folders and the organization are laid out.
2. Workloads: rough counts of Compute Engine instances, GKE clusters, Cloud Run and Cloud Functions services, Cloud SQL and BigQuery datasets, and storage buckets.
3. Identity: how many service accounts, whether user-managed keys are in use, whether workload identity federation is enabled, and how external identities federate in.
4. Access for the test: read-only access for the configuration review, such as the Security Reviewer role at the organization level plus viewer roles for the services in scope, and test identities that mirror real roles for the attack-path testing.
5. Applications: which apps and APIs run in GCP, and whether to test them in the same engagement through API penetration testing or a web application test.
6. Starting points: which footholds to model, from a standard employee to an internet-only attacker.
7. Compliance driver: SOC 2, PCI DSS, HIPAA or NYDFS, since it sets which projects are in scope and what each finding is mapped to.

Compliance and GCP

What each framework expects when the in-scope systems run on Google Cloud:

Framework	What it means on GCP
SOC 2	Auditors expect the projects that host the service, and the IAM that controls them, to be inside the tested scope
PCI DSS	Requirement 11.4 covers the cardholder data environment in GCP, including proof that VPC firewall rules and project boundaries actually isolate it
HIPAA	The Cloud Storage buckets, Cloud SQL instances and BigQuery datasets holding ePHI belong in the evaluation of your safeguards
NYDFS Part 500	The annual penetration test of a covered entity’s information systems includes the ones running in Google Cloud

What GCP penetration testing costs

Our cloud penetration testing starts at $6,800 for a single cloud account on one provider, which on Google Cloud usually means one project, fixed in writing before work begins. Several projects, with GKE or serverless workloads tested alongside, start at $10,500, and large estates with many projects and folders, or more than one cloud, start at $17,500. The price is the same whether you run on Google Cloud, AWS or Azure, and it covers both the configuration review and the attack-path testing, the report, and a free retest once your fixes are in. The tiers are on the cloud penetration testing cost page.

Frequently asked questions

Do I need Google’s permission to run a GCP penetration test? No. Google does not require you to contact it before testing your own projects. You must follow the Acceptable Use Policy and Terms of Service and test only your own resources, and a testing firm needs your written authorization.

Can I run a denial-of-service test on Google Cloud? No. The Acceptable Use Policy prohibits disrupting or impairing the services. DoS and resource-exhaustion testing against the platform are out of scope; resilience testing is handled separately.

Are Security Command Center findings enough? No. They tell you which settings are wrong, which is the configuration review. They do not tell you that a bucket your web server can read holds a service account key with rights in other projects, which is the kind of chain an attacker actually uses.

What is the highest-value target in GCP? Identity, specifically service accounts and the permissions that let one identity impersonate or attach another. Most serious GCP findings start or end there, not on the network.

How long does it take? For a single project, plan on about a week of testing, followed by the report and, after you fix, the retest. The count of projects and service accounts drives the time more than the count of VMs, and GKE or serverless workloads add to it. See how long a penetration test takes.

The short version

GCP penetration testing is allowed on your own projects without Google’s approval, within the Acceptable Use Policy. The work centers on identity: broad basic roles, over-privileged and default service accounts, keys that do not expire unless you set an expiry, and the impersonation and attach permissions that chain them together, with the metadata server turning an app-layer SSRF into cloud credentials. A good test pairs a benchmark configuration review with attack-path testing that proves what an attacker reaches. If you run on Google Cloud and want to know what one leaked key exposes, scope a cloud assessment. Comparing firms first? See the cloud penetration testing companies list.