☸️ Kubernetes Review Map — CKS Domains and Modern Attack Paths

Intro: Public Kubernetes security guides are most useful when they provide a review structure, not just a pile of commands. This page translates a CKS-style domain model and a modern attack-vector catalog into an enterprise Product Security review map: what to inspect first, what controls matter most, and where the deeper KB pages already live.

What this page includes

a Kubernetes security review model organized around the major CKS domains

a short list of attack paths that deserve explicit review in 2026

a practical minimum operating stack for preventive, detective, and investigative control layers

snippet and cross-link guidance into the rest of this KB

Why use a CKS-style map inside a Product Security KB

A certification map is not the goal. The value is that it gives teams a memorable review shell covering:

cluster setup and hardening;
system hardening;
workload and microservice restrictions;
supply-chain trust;
monitoring, logging, and runtime response.

That is close to how platform teams actually divide ownership.

Domain map translated into security review work

Review domain	What to ask first	Controls that usually matter most	First evidence to retain	First KB page
Cluster setup and hardening	is the control plane and network shape safe by default?	API server hardening, audit policy, ETCD protection, ingress exposure review, network policies, benchmark alignment	cluster baseline review, audit policy, exposed entry-point inventory	Kubernetes Security Baseline
Cluster hardening and access	can operators, workloads, or namespaces do more than they should?	RBAC cleanup, namespace boundaries, service-account scoping, kubelet hardening, anonymous-access review	RBAC diff, privileged binding review, kubelet config review	Kubernetes API Access Hardening
System hardening	how much host or runtime trust is available to a compromised workload?	node baseline, kernel controls, seccomp/AppArmor, runtime isolation, reduced host attack surface	node baseline, runtime profile settings, exception list	Kubernetes Hardening
Minimize microservice vulnerabilities	do workloads run with minimal privileges and clean boundaries?	Pod Security Admission, securityContext, secret handling, hostPath restrictions, least-privilege network policy	namespace policy labels, workload exceptions, sensitive mount review	Kubernetes Top 10 Misconfigurations
Supply-chain security	can untrusted artifacts, manifests, or policies enter the cluster?	image scanning, SBOM, signing, admission policy, approved registries, CI trust boundaries	image digest, signature / attestation record, scanner output	Trusted Images, Harbor, and Signing
Monitoring, logging, and runtime security	would we know if the cluster were abused after deployment?	audit logging, runtime detection, cluster telemetry, investigation workflow, cloud signal integration	alert trail, audit events, runtime detections, incident notes	Runtime Investigation Playbook for Kubernetes and Containers

Attack paths that deserve explicit review in 2026

These cases are repeatedly missed because they sit between “baseline hardening” and “actual attacker workflow”.

Attack path	Why teams miss it	First preventive controls	First detective / review controls
Kubelet anonymous or weak auth exposure	platform teams assume kubelet is internally safe by default	disable or tightly control anonymous auth, require kubelet authn/authz, network restrict node APIs	node exposure review, kubelet config audit, API access logs
Overprivileged service accounts and token projection abuse	service accounts accumulate privileges over time	explicit service accounts, minimal RBAC, token audience and lifetime discipline, avoid unnecessary automount	token usage review, who-can checks, privileged binding review
Ephemeral debug containers and `exec` abuse	troubleshooting paths bypass normal deploy review	restrict who can debug or exec, review break-glass process, log debug usage	audit `exec`, `attach`, and debug activity; incident review workflow
HostPath and privileged workload escape paths	operational shortcuts become permanent	Pod Security Admission, admission policy, exception tracking, host mount review	privileged workload inventory, namespace exception review
Cloud metadata service abuse from pods	cloud identity is treated as “outside Kubernetes”	metadata restrictions, workload identity, network egress controls, namespace isolation	egress review, unusual credential use, cloud IAM anomaly review
ImagePullSecrets theft and registry credential reuse	registry access is broader than needed	avoid broad shared pull secrets, use workload identity where possible, namespace separation	secret inventory, secret mount review, registry access logs
Persistent volume data exposure	storage reuse and orphaning are treated as operations-only issues	PVC lifecycle discipline, access mode review, encryption and sanitization process	orphaned volume review, storage inventory, data exposure tabletop
Admission bypass or inconsistent policy layers	teams deploy PSA, Kyverno, and Gatekeeper without ownership clarity	one clear policy stack design, namespace policy labels, exception workflow, test coverage for policy	policy drift review, denied-event review, exception registry

A practical minimum Kubernetes security stack

Early / minimum stack

Pod Security Admission for baseline workload restriction
Trivy or equivalent for image and config scanning
Kube-Linter or equivalent for manifest linting
Kubescape or equivalent for posture and benchmark visibility
Falco or Tetragon for runtime detection once ownership exists
Audit logging exported off-cluster

Better operating stack

Add:

Kyverno or OPA Gatekeeper for policy beyond PSA
Cilium or Calico with network-policy ownership
Cosign or equivalent signing / verification flow
RBAC analysis tools such as kubectl-who-can or rakkess
forensics helpers and a written runtime investigation workflow