← ALL ARCHITECTURE

Architecture

Production Security

Defence in depth on a GKE estate: every layer assumes the one in front of it has already been breached. Nothing here trusts the network.

scroll to render
01

What you're looking at

Four tiers, read top to bottom. Edge absorbs hostile traffic before it reaches an origin. Identity replaces network trust with cryptographic identity — federated tokens for workloads, short-lived certificates for humans. Runtime enforces what may execute and how it may talk. Detect records what happened. The attacker node on the right holds a genuinely valid stolen credential, and its path is drawn blocked at the VPC Service Controls perimeter — that single edge is the argument for the whole design.

02

Why the perimeter is the interesting control

Every other control on the diagram reduces the chance of compromise. VPC Service Controls is the only one that still helps afterwards. A valid token used from outside the perimeter is refused, which turns credential theft from a data-exfiltration event into a blocked request in an audit log.

03

What goes wrong here

Perimeters get configured around the wrong services — the one holding the data is omitted and the perimeter is decorative. Binary Authorization gets a break-glass exemption for an urgent deploy and the exemption is never removed. And Workload Identity is rolled out alongside the old service-account keys rather than instead of them, so the static credential everyone was worried about is still sitting there, now unused and unmonitored.

Inspect it yourself

  • Any static keys left?

    for sa in $(gcloud iam service-accounts list --format='value(email)'); do n=$(gcloud iam service-accounts keys list --iam-account=$sa --managed-by=user --format='value(name)' | wc -l); [ "$n" -gt 0 ] && echo "$sa: $n key(s)"; done

    Empty output is the goal. Anything listed is a credential with no expiry that someone could still be carrying.

  • Does the perimeter cover the data?

    gcloud access-context-manager perimeters describe PERIMETER --policy=POLICY --format='value(status.restrictedServices)' | tr ',' '\n'

    storage.googleapis.com, bigquery.googleapis.com and secretmanager.googleapis.com should all appear. A perimeter without them protects nothing that matters.

  • Who changed permissions this week?

    gcloud logging read 'protoPayload.methodName="SetIamPolicy"' --freshness=7d --format='table(timestamp, protoPayload.authenticationInfo.principalEmail, resource.type)'

    Nearly every privilege-escalation path passes through an IAM policy change. It is the highest-signal audit query there is.

  • Is Binary Authorization actually enforcing?

    gcloud container binauthz policy export | grep -E 'evaluationMode|enforcementMode'

    ALWAYS_ALLOW anywhere in the output means the control is present but switched off — a common state after an urgent deploy.

Read the source

Components

  • INTERNET— assume hostile
  • CLOUD ARMOR— WAF · DDoS · rate limit
  • LOAD BALANCER— TLS termination
  • WORKLOAD IDENTITY— no static keys
  • VPC SERVICE CONTROLS— data exfil perimeter
  • TELEPORT— short-lived certs · MFA
  • BINARY AUTH— signed images only
  • PRIVATE GKE— no public endpoint
  • ISTIO mTLS— STRICT · pod to pod
  • SECRET MANAGER— rotated · never in git
  • SECURITY COMMAND CTR— posture + findings
  • AUDIT LOGS— who did what, when
  • ATTACKER— stolen credential

Flows

  • internet→armorall ingress
  • armor→lbfiltered
  • lb→gkemTLS only
  • wif→gkefederated identity
  • teleport→gkehuman access
  • binauthz→gkeadmission
  • gke→mesh
  • secrets→gkeat runtime
  • vpcsc⇢secretsperimeter
  • gke→auditevery action
  • gke→sccposture
  • attacker⇢vpcscBLOCKED

Part of this work

Zero-Trust Access Migration ↗

Deleted the bastion hosts. Every VM, cluster and pipeline behind MFA.

Other systems