GKE security architecture

Use layers: identity, admission, workload, network, data, supply chain, detection, and response.

Harden access

Use groups, IAM, Kubernetes RBAC, and least privilege. Use Workload Identity Federation for Pods. Restrict control-plane and node exposure. Avoid broad cluster-admin, service-account keys, default service accounts, and anonymous access.

Harden Pods

Run as non-root, drop Linux capabilities, prevent privilege escalation, use a read-only root filesystem where possible, select seccomp, avoid host namespaces and hostPath, and enforce Pod Security Standards or Policy Controller rules. Autopilot enforces many constraints by default.

Protect the supply chain

Build in controlled pipelines, scan source and images, store images in Artifact Registry, generate provenance/SBOMs, sign approved artifacts, and use Binary Authorization to restrict deployment. Pin images by digest for high-assurance releases.

Network and data

Use private nodes, Dataplane V2, default-deny NetworkPolicy, Cloud Armor, encryption, Secret Manager, Cloud KMS, and minimal egress. Remember that network policy needs an enforcement dataplane.

Detect and respond

Use Cloud Audit Logs, GKE security posture, Security Command Center, Cloud Logging, Cloud Monitoring, and policy/audit findings. Define containment: disable identity, quarantine namespace/workload, block image, preserve evidence, rotate secrets, redeploy trusted artifacts, and review blast radius.

Official source: GKE security best practices.