Google Cloud security
We assess and harden Google Cloud where it actually fails — inheritance in the resource hierarchy, service account impersonation chains, GKE workload identity, and the perimeter around your data.
When you need this
You started with one Google Cloud project and now run a hundred across folders nobody has revisited since the hierarchy was drawn.
Someone still holds Editor on the production project, service account keys exist in places you can't fully account for, and you need to know how bad that actually is.
You're moving regulated or customer data into BigQuery and need a defensible answer to "what stops this leaving?"
Your team knows AWS. Google Cloud arrived with an acquisition or a data-platform decision, and the patterns you trust don't transfer cleanly.
What we do
01
Start at the organization node, not the project
Most Google Cloud problems are inheritance problems. We read the hierarchy from the org down through folders and projects, then check which organization policy constraints are enforced and where an exception quietly turned one off — public access prevention on Cloud Storage, external IP restrictions on Compute Engine, domain-restricted sharing, service account key creation. Dry-run mode shows what enforcing a constraint would break before you enforce it, and custom constraints cover the rules the built-in set doesn't. IAM deny policies get the same treatment: useful, but only when they sit above the grants people keep re-creating.
02
Identity is a graph of impersonations
Basic roles — Owner, Editor, Viewer — still sit on production projects in most environments we see, often on the default compute service account that every VM inherits. We replace the "who has what" list with a reachability graph: who holds roles/iam.serviceAccountTokenCreator or iam.serviceAccounts.actAs on which service account, where those chains cross an environment boundary, and which user-managed keys exist that shouldn't. IAM Conditions get read for what they really constrain, because CEL expressions on resource.name and request.time are easy to write so they look restrictive and aren't. Workload identity federation is where we spend real time: a provider with no attribute condition, bound at the pool level rather than to a specific attribute.repository, lets any repository on GitHub assume that service account.
03
GKE, where cluster identity meets project identity
The starting question is what a pod reaches once it's compromised. That means Workload Identity Federation for GKE genuinely enabled with the GKE metadata server blocking node-credential access, node pools running a dedicated service account instead of the default compute one, and Kubernetes RBAC reviewed alongside the container IAM roles that grant cluster access from outside the cluster. We check Binary Authorization end to end — attestors, the policy that admits images, whether continuous validation is on, and whether break-glass is logged or routine. Then the unglamorous controls that set blast radius: private control plane with authorized networks, Shielded GKE nodes, Pod Security Admission, and network policy that denies by default.
04
The data perimeter, and whether you'd see it fail
VPC Service Controls is the control most often half-built: a perimeter around some services but not BigQuery or Cloud Storage, egress rules broad enough to make it decorative, or a config left in dry-run for a year. We design perimeters against your real data flows, then examine BigQuery directly — authorized views and datasets, column-level policy tags, row-level access policies, and who can run bq extract to a bucket outside the boundary. Detection gets tested the same way. Admin Activity logs are always on, but Data Access logs are off by default for most services, so the reads you would most want evidence of are usually the ones nobody records, and Security Command Center findings often route nowhere a human or a pipeline acts on.
What you receive
- A hierarchy map — org, folders, projects — showing which policy constraints inherit where and which exceptions break the pattern
- A service account impersonation graph: who can become what, and which chains cross a project or environment boundary
- An organization policy baseline as Terraform, with dry-run results so you know what breaks before you enforce it
- Per-cluster GKE hardening plan that separates what Autopilot already enforces from what you own
- VPC Service Controls perimeter and ingress/egress rules written against your data flows, not a template
- Audit log and Security Command Center coverage gaps, with the sink and alerting changes that close them
How it runs
Scope
days
Read-only access agreed at the org or folder node, projects and data boundaries confirmed, fixed price set.
Assess
1–3 weeks
Automated inventory across the hierarchy, then manual review of identity paths, GKE posture, and data boundaries.
Readout
days
Prioritised findings with hierarchy and impersonation diagrams, mapped to CIS Google Cloud Platform Foundation Benchmark controls where they apply.
Verify
included
We re-check the changes you make, including constraints moved from dry-run to enforced.
Durations are indicative. Actual scope and price are fixed after the scoping call.
Questions we get asked
- Do you need Owner or Organization Administrator?
- No. Read-only covers the assessment: roles/viewer and roles/iam.securityReviewer at the org or folder node, plus Cloud Asset Inventory and log read access. You create the principal, you scope it, you revoke it when we're done. If you want us to implement fixes rather than write them, that's a separate and narrower grant agreed in writing.
- We already run Security Command Center. What does an assessment add?
- Security Command Center's detectors score one resource against one rule — this constraint is unset, this bucket is public, this key is overdue for rotation. They have no view of intent. Nothing in the product tells you that your VPC Service Controls perimeter was drawn around the wrong set of services for how the data actually moves, that its egress rules make it decorative, or that a build service account in a sandbox project can be impersonated all the way into the project holding customer records. We read your open findings first so we aren't re-reporting them, then work on the design decisions underneath. One honest caveat: what we hand back is reasoning from read access, not proof. If you need the impersonation chain walked and the data shown leaving, that's a cloud penetration test, not this.
- Most of our estate is Autopilot and Cloud Run. Isn't Google securing it for us?
- Google secures the substrate — node image, control plane patching, the sandbox your container runs in. What's left is the part that usually causes the incident. On Autopilot you still own Workload Identity Federation bindings, Kubernetes RBAC, network policy, image provenance, and which service account each workload runs as; Autopilot narrows the node-level attack surface, it doesn't decide what your pod can reach. On Cloud Run the risk is almost entirely configuration: roles/run.invoker granted to allUsers, ingress left open on a service only ever meant to be internal, a runtime service account still inheriting project Editor, and secrets passed as plain environment variables instead of mounted from Secret Manager. We assess all of that. What we don't do is test Google's side of the line — we don't attempt sandbox escape or probe Google-managed infrastructure, and Google's Vulnerability Reward Program is the route for anything there.
- Do you cover Google Workspace as well?
- Only where it touches Google Cloud — super admin accounts, group-based role grants, and domain-restricted sharing, because those decide who can reach your projects. Full Workspace administration, including Drive and Gmail data controls, device management, and Chrome policy, is a different discipline and we don't claim it. We'd rather scope it out than bill for a shallow pass.