Google Cloud security assessment
Service account impersonation is the story on GCP. Project-level bindings hand out far more than teams realise.
The context
What actually breaks on Google Cloud
Google Cloud has the cleanest permission model of the three large providers and, partly because of that, the one teams most often over-grant on. Project-level bindings are easy to apply and it is rarely obvious how much they hand over.
Service account impersonation is the mechanism worth understanding. If a principal holds roles/iam.serviceAccountTokenCreator on a service account, it can act as that service account. Chain two or three of those and a modest starting position becomes project Editor. The individual bindings each look defensible in review.
Exportable service account keys are the other recurring issue. They do not expire, they are frequently committed to repositories, and organisation policy can disable their creation entirely. Most estates we assess have keys older than the engineers who created them.
Assessed surfaces
Everything we look at on Google Cloud.
- 01IAM bindings, primitive roles & service account impersonation chains
- 02Service account keys, existence, age and export exposure
- 03Cloud Storage bucket IAM, uniform access & public objects
- 04VPC firewall rules, Cloud Armor, external load balancer exposure
- 05Secret Manager access, Cloud KMS key permissions
- 06GKE workload identity, RBAC, node pool & control plane exposure
- 07Cloud Audit Logs coverage, sink integrity, org policy constraints
Questions
Google Cloud FAQ
roles/viewer plus roles/iam.securityReviewer at the organisation or folder level, depending on scope. Read-only. Organisation-level visibility matters because org policy constraints and folder-level bindings are where a lot of the real controls live.
Yes. Workload Identity configuration, cluster RBAC, whether the control plane is publicly reachable, and node service account permissions. A pod running with the default node service account is a common and underrated path from a container compromise to project-level access.
We check which constraints are enforced and which are not, because org policy is the most effective control GCP offers and it is routinely left at defaults. Disabling service account key creation, restricting public IP on VMs, and enforcing uniform bucket-level access remove entire finding classes at once.
Other platforms we assess
A CI role assumable from an unrestricted GitHub OIDC condition, chaining into production admin.
AWS assessmentAn app registration holding a long-lived client secret with directory-wide Graph permissions.
Azure assessmentA read-write API token in a build environment variable, with no expiry and no rotation record.
DigitalOcean assessmentFind out what is reachable in your Google Cloud estate.
Read-only access, one to two weeks, fixed price. You get attack paths with proof, not a posture score.
No sales sequence. A scoping call and a written proposal cost nothing.