Lab 05 — Google Cloud Landing Zone and GKE Defense

Difficulty: 5/5 | Provider: Google Cloud

Pairs with the whole Phase 07 WARMUP. Build the evaluator first; reproduce only in a disposable organization or approved sandbox. Apply the same attack-path reasoning as the AWS lab (04) in Google Cloud's model.

Why This Lab Exists (Purpose & Goal)

The same landing-zone principles — secure foundation, identity as perimeter, guardrails, protected logging, recovery — apply to every cloud, but the mechanisms differ, and a security engineer must be able to reason in each provider's model rather than transplanting another's assumptions. The goal of this lab is to build, attack, and defend a Google Cloud landing zone, internalizing GCP's distinctive controls (the resource hierarchy, service-account impersonation, workload-identity federation, VPC Service Controls).

The Concept, In the Weeds

The attack story: a compromised external CI identity attempting to cross workload-identity federation, impersonate a service account, escape a project boundary, exfiltrate managed data, and suppress evidence. The GCP-specific controls and their pitfalls:

  • Service-account impersonation is GCP's central escalation edge — iam.serviceAccountTokenCreator on a privileged SA is a path to its authority; bind it narrowly.
  • Workload Identity Federation (WIF) lets external systems (CI) mint short-lived credentials — its attribute conditions must constrain exactly which external subject is trusted, or any repo can impersonate.
  • VPC Service Controls create a data-exfiltration perimeter around managed services — but it is a data-exfiltration control with compatibility limits, not a general network firewall (a critical distinction many get wrong).
  • Organization policies, domain-restricted sharing, custom roles are the guardrails; aggregated log sinks with separated access protect evidence (the compromised project must not be able to delete its own audit trail).
  • Private GKE + workload identity keeps the cluster off the public internet and gives pods scoped cloud identity instead of node credentials (the K8s-to-cloud pivot, GCP edition).

Why This Matters for Protecting the Company

If the company runs on Google Cloud, this is the foundation that bounds every workload's blast radius. A loose WIF attribute condition is a direct path from a public CI system into your cloud; an unprotected log sink lets an attacker erase their tracks; a missing VPC SC perimeter lets exfiltration flow out of managed data stores. Building the GCP landing zone as a security product — and being able to reason fluently in GCP's hierarchy/impersonation/perimeter model, not just AWS's — is how you protect a Google Cloud estate and how you stay effective at companies that are multi-cloud.

Build It

LAB_MODULE=solution pytest -q

Then reproduce only in a disposable organization or approved sandbox. Test organization policies, domain-restricted sharing, custom roles, service-account token creation, WIF attribute conditions, VPC Service Controls, private GKE, Cloud KMS separation, Data Access logs, aggregated sinks, Security Command Center findings, and emergency revocation.

The hardened result must include: a resource-hierarchy diagram, IAM and impersonation graph, ingress/ egress matrix, perimeter-bridge review, GKE workload-identity tests, log-sink access separation, canary detections, restore exercise, teardown, and cost evidence.

Validation — What You Should Be Able to Do Now

  • Reason about GCP authority in terms of the resource hierarchy and service-account impersonation, and constrain WIF attribute conditions to an exact external subject.
  • Explain that a VPC Service Controls perimeter is a data-exfiltration control with compatibility limits, not a network firewall.
  • Separate log-sink access so a compromised project cannot suppress its own evidence.

The Broader Perspective

Doing the same landing-zone exercise across AWS (04), GCP (05), and Azure (06) teaches the most important multi-cloud lesson: the principles are universal (identity perimeter, guardrails, protected logging, least-privilege workload identity, blast-radius containment), but the mechanisms and their sharp edges are provider-specific. A senior cloud-security engineer carries the patterns and learns the mechanisms, rather than memorizing one provider and assuming the others work the same way. That transferable-principles-plus-provider-specifics mindset is what lets you secure whatever cloud the company actually uses.

Interview Angle

  • "Compare workload-identity approaches across clouds." — All replace stored static keys with attested, short-lived, audience-scoped credentials; GCP uses service-account impersonation and WIF attribute conditions, AWS uses role trust policies + OIDC, Azure uses federated credentials — same goal (kill the long-lived secret), different binding mechanism. The skill is constraining which external subject is trusted.

References

  • Phase 07 WARMUP; Google Cloud security foundations / Architecture Framework.
  • Workload Identity Federation, VPC Service Controls, Security Command Center documentation.