Kubernetes Security Best Practices for CKS 2026: Hands-On Hardening Guide

The CKS exam tests whether you can implement, not recite, Kubernetes security controls. The CNCF curriculum is built on the same 12 practices that production-grade clusters at scale already use. Learn them well enough to deploy under exam time pressure and you have both the certification and a defensible cluster.

The Kubernetes Threat Model

Before any control matters, you need a clear picture of how attackers actually get in. The realistic 2026 Kubernetes threat model has five primary pathways:

Compromised container image. A base image (or a transitive dependency) contains a known CVE or a backdoored binary. Once deployed, the attacker has code execution inside your cluster from day one. Mitigations: image scanning, signed images, distroless or minimal bases, SBOMs.

Container escape. A vulnerability in the container runtime (runc, containerd), kernel, or a misconfigured privileged pod lets a process break out to the host. Once on the host, the attacker reads kubeconfig, hits the kubelet API, or pivots to other pods. Mitigations: Pod Security Standards (restricted), seccomp, AppArmor, runtime sandboxes (gVisor / Kata).

Exposed API server. An unauthenticated or under-authenticated kube-apiserver, dashboard, or kubelet read-only port reachable from the internet. Catastrophic if found. Mitigations: network restrictions, OIDC, anonymous-auth=false, audit log alerts on anonymous calls.

Lateral movement. An attacker who compromised one pod reaches every other pod in the cluster because no NetworkPolicy exists. They scan, pivot, harvest credentials, escalate. Mitigations: default-deny NetworkPolicies, mTLS via service mesh, ServiceAccount tokens scoped per workload.

Supply chain compromise. A build pipeline, CI runner, or artifact registry is breached and malicious code is signed and shipped through the normal channel. Mitigations: SLSA-style provenance, signed commits, ephemeral CI runners, signed images verified at admission.

Practice 1 — Hardened Cluster Setup

Start with the CIS Kubernetes Benchmark. Run kube-bench against your control plane and worker nodes — it scores every CIS control and tells you exactly which YAML field to change. Critical hardening items: encrypt etcd at rest (--encryption-provider-config on kube-apiserver pointing at an EncryptionConfiguration), restrict the API server to known CIDRs via cloud-provider firewall (never "0.0.0.0/0"), disable anonymous auth (--anonymous-auth=false), disable the insecure port (deprecated, but verify), and rotate kubelet and apiserver certificates with sub-1-year expiry. Run kube-bench monthly and treat findings like CVEs.

Practice 2 — RBAC Least Privilege

Default to view and build up. Start every new ServiceAccount with no bindings, then add a Role with the minimum verbs and resources needed for that workload — never a ClusterRole unless cluster-scoped resources are involved. Audit existing ClusterRoleBindings monthly with kubectl get clusterrolebindings -o yaml | grep -i admin. Disable automatic ServiceAccount token mounting on workloads that do not need API access (automountServiceAccountToken: false). One ServiceAccount per workload, never sharing. Verify changes with kubectl auth can-i before considering RBAC tasks done.

Practice 3 — Pod Security Standards

Pod Security Policies (PSP) were removed in Kubernetes 1.25. The replacement is Pod Security Standards (PSS) enforced via the built-in Pod Security Admission controller. Three profiles: privileged (unrestricted), baseline (prevents known privilege escalation), restricted (CIS-hardened, no root, no privilege escalation, seccomp RuntimeDefault). Default every namespace to restricted by labelling: kubectl label ns prod pod-security.kubernetes.io/enforce=restricted. Use baseline only as an explicit exception with a documented reason. For organisations needing more nuanced policy (e.g. allow capability X to specific deployments), layer Kyverno or OPA Gatekeeper on top.

Practice 4 — NetworkPolicies as Default Deny

Without NetworkPolicies, every pod can talk to every other pod — a textbook lateral movement opportunity. The pattern is default-deny + explicit allow: apply a NetworkPolicy that selects all pods and denies all ingress and egress, then add allow policies for the specific flows you need (frontend to API, API to DB, all pods to DNS on UDP 53). Use a CNI that actually enforces NetworkPolicies — Cilium, Calico, and Weave are the common choices. Verify by running kubectl exec into a pod and trying to curl something that should be blocked.

Practice 5 — Image Scanning with Trivy

Trivy is the de facto standard for container image scanning and is heavily exam-tested. Two integration points: CI gate (trivy image --severity HIGH,CRITICAL --exit-code 1 myimage:tag in the pipeline blocks merge on findings) and admission control (use Trivy Operator or an image-policy webhook to scan at deploy time and reject vulnerable images). Pair with a vulnerability database refresh cadence (Trivy auto-updates) and an exception process for unfixable CVEs with documented compensating controls. Re-scan running images weekly — new CVEs are disclosed daily.

Practice 6 — Sign Images with Cosign

Image signing closes the supply chain loop: even if your registry is compromised, only correctly-signed images deploy. Cosign (from Sigstore) is the OpenSSF-blessed signing tool and is now part of the CKS curriculum. Workflow: build image, sign with Cosign using a keyless OIDC flow or a managed key (KMS), push signature alongside image, configure admission policy (Policy Controller, Kyverno verifyImages, or Sigstore Policy Controller) to require valid signatures from approved identities. Bonus: generate and attach an SBOM (cosign attach sbom) for downstream vulnerability tracking.

Practice 7 — Falco Runtime Detection

Admission control stops bad workloads at deploy time, but runtime detection catches what slipped through. Falco watches syscalls via eBPF or a kernel module and matches them against rules. Out-of-box rules detect shell-in-container, sensitive file reads (/etc/shadow), package manager runs in production pods, unexpected outbound network connections, and privileged container starts. Write custom rules for your environment (e.g. "alert if anything writes to /app/config in pod label X"). Route alerts via Falcosidekick to Slack, PagerDuty, or your SIEM. Without runtime detection, you are blind once an attacker is past admission.

Practice 8 — Seccomp and AppArmor Profiles

Seccomp filters syscalls; AppArmor restricts file and capability access. Both reduce the kernel attack surface available to a compromised container. Bare minimum: set seccompProfile.type: RuntimeDefault on every pod (the container runtime ships a sane default profile blocking ~50 dangerous syscalls). For sensitive workloads, generate a custom profile by running the workload under strace in staging and producing a tightened JSON. AppArmor profiles bind via pod annotation (container.apparmor.security.beta.kubernetes.io/<container>: localhost/<profile>) and the profile file must exist on the node. Pod Security Standards restricted already requires RuntimeDefault — getting PSS enforcement done gives you this for free.

Practice 9 — Secrets Management

Never store credentials in plain ConfigMaps and never in image layers. Kubernetes Secrets are base64-encoded by default, not encrypted — enable etcd encryption-at-rest (Practice 1). Better: pull secrets from an external store via External Secrets Operator (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault). For GitOps-friendly secrets, use SealedSecrets (Bitnami) — the sealed manifest is safe to commit. Rotate any secret on schedule; bind a workload's blast radius to one secret with mounted-volume Secrets (not env vars, which leak via process listings).

Practice 10 — Audit Logging

Without audit logs you cannot do incident response, period. Enable audit on kube-apiserver with --audit-policy-file and --audit-log-path. Start with a balanced audit-policy.yaml that logs Metadata for most resources, Request for secrets and rbac changes, and skips noisy reads (events, endpoints). Ship logs off-cluster immediately (Fluent Bit / Vector to S3 + a SIEM). Retain 1 year minimum. Set alerts for: anonymous calls, exec into pods in prod, unauthorised verbs from ServiceAccounts, secret access by unexpected identities.

Practice 11 — gVisor or Kata Containers for Untrusted Workloads

For multi-tenant clusters, customer-supplied code, or genuinely untrusted workloads, runC's kernel sharing is not enough. gVisor (Google) intercepts syscalls in user-space; Kata Containers run each pod in a lightweight VM. Both define a RuntimeClass resource; workloads set runtimeClassName: gvisor to opt in. Performance hit is real (10-30% depending on workload), so reserve for workloads that justify it.

Practice 12 — Continuous Posture Management

Security drift is real — a cluster passing kube-bench today fails next week after a node upgrade or a hot-fixed manifest. Automate posture checks: kube-bench daily as a CronJob with results shipped to a dashboard, Trivy scanning the running images in every namespace, Polaris or Datree gating manifests at admission. Larger orgs add a CSPM platform (Wiz, Prisma Cloud, Lacework, Sysdig Secure) that correlates K8s posture with cloud posture for end-to-end visibility.

How These Map to CKS Exam Domains

Quick reference for exam prep prioritisation:

If you can implement all 12 in a kubeadm lab from scratch in under 4 hours, the CKS exam will feel like an extended version of practice. See our CKS exam tips guide for the time-management strategies that turn practice fluency into a passing score.

Frequently Asked Questions

What are the 4Cs of cloud-native security?

Cloud, Cluster, Container, Code. From the official Kubernetes security guide — defence in depth across all four layers.

Is Pod Security Policies still used?

No. PSPs were removed in K8s 1.25. Pod Security Standards (PSS) replaced them, enforced via admission webhook or OPA/Kyverno.

What's the difference between admission and runtime security?

Admission security blocks bad workloads at deploy time (OPA, Kyverno, image-policy webhook). Runtime security detects behaviour anomalies on running workloads (Falco, Tetragon).

Is image scanning enough for supply chain security?

No. Add image signing (Cosign), SBOM generation, admission control on signature, and vulnerability monitoring of running images (image drift).