k8s Pod Security Policy: Why It Was Removed and What Replaced It

The k8s Pod Security Policy (PSP) no longer exists: it was deprecated in Kubernetes 1.21 and fully removed in 1.25, replaced by the built-in Pod Security Admission controller and the Pod Security Standards. If you are still searching for how to write a PodSecurityPolicy, the short answer is that you cannot on any supported cluster, and any tutorial telling you to is out of date. This guide explains why Pod Security Policy in Kubernetes was retired and what to use instead.

What PSP was supposed to do

A PodSecurityPolicy was a cluster-level resource that controlled the security-sensitive fields of a pod spec: whether it could run privileged, use host networking, run as root, mount hostPath volumes, or escalate privileges. In theory it was the guardrail that stopped a workload from asking the kubelet for dangerous capabilities.

In practice it was hard to use correctly, and that difficulty is exactly why it was removed.

Why Kubernetes removed it

The deprecation was not arbitrary. PSP had structural problems that the maintainers concluded could not be fixed without a redesign:

• Confusing authorization model. PSP enforcement depended on RBAC bindings between the requesting user or service account and the policy object. A pod was allowed if any policy the requester could use permitted it, which meant the "most permissive wins" behavior surprised almost everyone. Misconfigured bindings silently disabled enforcement.
• No dry-run or audit mode. You could not safely test a policy against existing workloads before enforcing it. Turning on a strict PSP could instantly break running pods with no warning.
• Inconsistent behavior across clusters. The mutation-plus-validation design meant PSP could quietly change pods, and the ordering of policies produced results that differed between environments.

The combination made PSP something teams either avoided entirely or enabled and then got burned by. Rather than patch it forever, Kubernetes deprecated it in 1.21 and removed it in 1.25.

What replaced it: Pod Security Admission

The replacement is Pod Security Admission (PSA), a built-in admission controller enabled by default since 1.25, which enforces the Pod Security Standards (PSS). The standards define three profiles:

• Privileged — unrestricted, for trusted infrastructure workloads.
• Baseline — blocks known privilege escalations while staying broadly compatible with common applications.
• Restricted — the hardened profile, following pod-hardening best practices like running as non-root, dropping all capabilities, and disallowing privilege escalation.

The genius of the replacement is its simplicity. Instead of authoring policy objects and wiring RBAC, you label a namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Three modes make migration safe in a way PSP never allowed:

• enforce rejects non-conforming pods.
• audit records violations in the audit log without blocking.
• warn returns a warning to the user who submitted the pod.

You can set warn and audit to restricted first, watch what would break, and only flip enforce once you have fixed the offenders. That built-in dry-run capability is the single biggest improvement over PSP.

How to migrate off PSP

If you are upgrading a cluster that predates 1.25 or maintaining old manifests, the migration path is well trodden:

1. Inventory your PSPs and the pods they cover. Map each policy to a Pod Security Standard profile. Most "allow almost anything" PSPs map to Baseline; genuinely hardened ones map to Restricted.
2. Label namespaces in warn and audit mode at the target profile. Do not enforce yet.
3. Fix the violations. The warnings and audit entries tell you which workloads request root, privileged mode, or host access. Rework those pod specs, or move truly privileged infrastructure into a namespace labeled privileged.
4. Flip to enforce namespace by namespace once it is clean.
5. Remove the PSP objects and the associated RBAC once nothing depends on them.

A critical warning: if you upgrade a cluster to 1.25 or later without migrating, PSP enforcement simply disappears. Your pods will still run, but the guardrails are gone and your posture silently weakens. Do the migration before the upgrade, not after.

When you need more than the three profiles

Pod Security Admission is deliberately simple, and three fixed profiles do not cover every rule an organization wants to enforce. For anything beyond the standard profiles, such as requiring specific image registries, enforcing resource limits, or custom label policies, use a general-purpose policy engine like Kyverno or Open Policy Agent Gatekeeper alongside PSA. Many teams run PSA for the baseline pod-hardening and a policy engine for organization-specific rules.

Whatever you enforce at admission time only matters if the images you admit are themselves sound. Pairing admission control with container image scanning closes the gap between "this pod is configured safely" and "this pod's image is free of known CVEs." Our academy covers building a layered Kubernetes security baseline that combines both.

FAQ

Is Pod Security Policy still available in Kubernetes?

No. PSP was deprecated in Kubernetes 1.21 and removed entirely in 1.25. It is not available on any current supported version. Use Pod Security Admission and the Pod Security Standards instead.

What replaced PodSecurityPolicy?

Pod Security Admission (PSA), a built-in admission controller, enforces the Pod Security Standards: the Privileged, Baseline, and Restricted profiles. You apply them by labeling namespaces rather than authoring policy objects.

What happens if I upgrade to 1.25 without migrating from PSP?

PSP enforcement is removed, so your pods keep running but without the restrictions the PSPs provided. Your security posture weakens silently. Migrate to PSA before upgrading.

Can Pod Security Admission enforce custom rules?

No, it only enforces the three fixed Pod Security Standard profiles. For custom policies such as registry allowlists or resource requirements, add a policy engine like Kyverno or OPA Gatekeeper alongside PSA.