Kubernetes security hardening is the practice of systematically reducing the attack surface of containerized workloads and cluster infrastructure by applying layered controls, from pod-level security contexts up to control plane configuration and supply chain integrity. The Pod Security Standards (PSS) and the Pod Security Admission (PSA) controller, stable since Kubernetes v1.25, give operators a built-in, namespace-scoped enforcement framework with three well-defined profiles, and later releases keep extending pod-level isolation further, most notably User Namespaces reaching general availability in v1.36 as a Linux-only, opt-in mapping of a container's root user to an unprivileged host user. The key mental model is defense-in-depth: no single control is sufficient; effective cluster security combines pod restrictions, RBAC, network policy, audit logging, runtime detection, and ongoing CVE response into overlapping layers.
What This Cheat Sheet Covers
This topic spans 17 focused tables and 113 indexed concepts, 108 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Pod Security Standards — Three Profiles
Pod Security Standards define three cumulative security profiles that range from fully permissive to highly restrictive. Every Kubernetes cluster has a built-in implementation through the Pod Security Admission controller, making these the foundational building block of workload security.
| Profile | Example | Description | |
|---|---|---|---|
pod-security.kubernetes.io/enforce: privileged | • Entirely unrestricted policy • allows all privilege escalation paths • Intended only for trusted system- and infrastructure-level workloads (e.g., CNI plugins, node agents). | ||
pod-security.kubernetes.io/enforce: baseline | • Minimally restrictive • prevents known privilege escalation vectors (host namespaces, privileged containers, dangerous capabilities, HostPath volumes, unsafe sysctls, and, since v1.34, the host field on probes and lifecycle hooks) while allowing default pod configurations for most application workloads | ||
pod-security.kubernetes.io/enforce: restricted | • Heavily restricted • follows current pod hardening best practices: requires non-root execution, drops ALL capabilities (only NET_BIND_SERVICE re-allowed), mandates seccomp, restricts volume types, and prohibits privilege escalation |