The Kubernetes documentation describes the built-in Pod Security admission controller as stable since Kubernetes 1.25. It applies Pod Security Standards at namespace level when Pods are created. The standards define privileged, baseline, and restricted profiles: privileged is unrestricted, baseline prevents known privilege escalations while supporting common workloads, and restricted follows current Pod-hardening practices.
Namespace labels select both a profile and a mode. enforce rejects a violating Pod. audit allows it but adds an annotation to the audit event. warn allows it but returns a user-facing warning. Each mode can also pin a Kubernetes policy version or use latest. A namespace can use different levels and versions for different modes.
The controller boundary matters. Audit and warning checks apply to workload resources such as Deployments and Jobs so template problems can be shown early, but enforcement applies to resulting Pod objects rather than the workload object itself. An accepted Deployment can therefore fail later when its controller tries to create noncompliant Pods.
\nStatic exemptions can match usernames, runtime classes, or namespaces. When an exemption matches, all enforce, audit, and warn behavior is skipped. Kubernetes cautions against broadly exempting controller service accounts because any user who can create the corresponding workload may inherit the bypass. The API server exposes evaluation, error, and exemption metrics for the admission controller.
\n\nCreate a register of every cluster and namespace with business service, owner, data sensitivity, internet exposure, node operating system, workload controller, intended Pod Security profile, pinned policy version, and exception status. Reconcile it against the live API. An unlabeled namespace is a governance finding even when its current Pods happen to satisfy the desired profile.
\naudit and warn at the intended profile to representative nonproduction namespaces. Capture violations from manifests, charts, operators, jobs, init containers, and generated workloads rather than relying on a scan of long-running Pods alone.Alert on namespace label changes, admission configuration changes, enforcement rejections, evaluation errors, and unexpected increases in pod_security_exemptions_total. Trend warnings by owner and profile, and verify that audit events reach the security logging destination. Pod Security Admission is a useful platform floor; it does not replace image provenance, vulnerability management, network policy, secrets protection, runtime detection, RBAC, or node hardening. The durable outcome is a known policy at every namespace and a short, reviewable path for the rare workload that cannot meet it.
Include namespace-label restoration in cluster recovery testing. A restored workload without its intended admission posture can look healthy while accepting weaker replacement Pods, so compare labels and exemption configuration with the governed inventory before reopening service.
\n\n