Enforce Kubernetes Pod Security Standards by namespace and exception

Source facts: three profiles, three modes, and important boundaries

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.

Static 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.

DSE recommendation: make namespace posture part of workload ownership

Create 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.

1. Observe first. Apply audit 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.
2. Assign remediation. Translate each field violation into a workload change, owner, target release, and test. Common fixes affect capabilities, privilege escalation, host namespaces, volumes, user identity, and security profiles; validate application behavior after changing them.
3. Version deliberately. Pin enforcement to the cluster minor version that has been tested. Consider audit and warn against the next intended or latest profile to expose future drift, but assess version changes during every cluster upgrade instead of silently inheriting new restrictions.
4. Stage enforcement. Start with a limited namespace class, deploy a known-violating test manifest to prove rejection, and confirm that compliant controllers still create and replace Pods. Test rollout, rollback, autoscaling, scheduled Jobs, disaster recovery, and node replacement.
5. Isolate privileged workloads. Place necessary infrastructure components in specifically governed namespaces. Restrict who can change namespace labels, create workloads there, select privileged runtime classes, or modify admission configuration. Keep ordinary applications out of that boundary.
6. Govern exemptions as bypasses. Record exact dimension, business reason, requester, approver, risk, compensating controls, affected workload, expiry, and removal test. Prefer the narrowest supported exemption and review controller-service-account implications before approval.

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.

Official references

• Kubernetes Documentation, Pod Security Admission, page last modified March 7, 2024; version-specific documentation reviewed August 11, 2026.
• Kubernetes Documentation, Pod Security Standards.