What replaced PodSecurityPolicy, and what does Pod Security Admission do?
Quick Answer
PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and removed in 1.25, replaced by **Pod Security Admission** — a built-in admission controller that enforces one of three predefined, non-customizable Pod Security Standards (`privileged`, `baseline`, `restricted`) at the namespace level, via a simple label on the namespace, rather than PSP's more complex and notoriously hard-to-reason-about custom policy objects and RBAC-based binding model.
Detailed Answer
Why PodSecurityPolicy was deprecated and removed
PSP let you define arbitrarily customizable security policies (allowed capabilities, allowed volume types, required user IDs, and much more) — but applying a PSP to a Pod worked through an unusually indirect mechanism: a PSP had to be granted via RBAC to a user or ServiceAccount, and which PSP actually applied to a given Pod depended on RBAC evaluation order in ways that were widely regarded as confusing and error-prone in practice. This complexity was cited as the primary reason for deprecating it in favor of something simpler.
Pod Security Admission — the replacement
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
Rather than custom policy objects, Pod Security Admission enforces one of three predefined, standardized levels (the Pod Security Standards), simply by labeling a namespace:
| Level | Behavior |
|---|---|
| privileged | Unrestricted — no security requirements enforced at all |
| baseline | Blocks known privilege-escalation paths (e.g., disallows privileged containers, host namespaces) while remaining broadly compatible with common workloads |
| restricted | The most hardened standard — requires non-root, disallows privilege escalation, requires dropping all Linux capabilities except a small allowed set, requires seccompProfile, and more |
Three separate label keys control three independent modes: enforce (actually reject non-compliant Pods), audit (allow them, but log a warning in the audit log), and warn (allow them, but return a warning to the user submitting the Pod) — commonly used together to warn/audit at a stricter level while only enforce-ing a more lenient one, giving teams visibility into what would be rejected under a stricter policy before actually flipping enforcement on.
Why this is a meaningful simplification
Pod Security Admission is deliberately less flexible than PSP was — you choose from three fixed levels rather than defining arbitrary custom rules — but this tradeoff was a deliberate design choice: most of PSP's complexity came from unlimited customizability that few teams actually needed and many implemented incorrectly. The three-level model covers the vast majority of real-world security posture needs with drastically simpler, namespace-label-based configuration that's much easier to reason about and audit.
What if you need more customization than the three standard levels offer
For genuinely custom policy needs beyond the three built-in levels, the ecosystem has moved toward general-purpose policy engines — OPA Gatekeeper and Kyverno are the two most widely adopted — which use admission webhooks (see that question) to enforce arbitrary custom policies, not limited to Pod security specifically (they can validate/mutate any Kubernetes object type against custom rules). Many clusters run Pod Security Admission for the baseline hardening it provides simply and natively, layered with a policy engine like Kyverno or Gatekeeper for anything requiring finer-grained or organization-specific rules.
Knowing that PSP was removed (not just deprecated) as of 1.25, and that Pod Security Admission trades PSP's flexibility for three simple, standardized levels specifically to fix PSP's usability/complexity problems, demonstrates awareness of a real, relatively recent, and commonly-tested Kubernetes ecosystem shift — not just familiarity with security concepts in the abstract.