Why Kubernetes removed PodSecurityPolicy and what replaced it

In a post on the Kubernetes Blog in August 2022, the project provided historical context for the removal of PodSecurityPolicy (PSP). This admission controller was officially removed in Kubernetes v1.25 after a long deprecation cycle that began with the v1.21 release. The article explains why PSP failed to reach stability and how its successor, Pod Security Admission, addresses those shortcomings.

What happened

PodSecurityPolicy originated from OpenShift’s SecurityContextConstraints (SCC), which existed in the first release of Red Hat OpenShift Container Platform before Kubernetes 1.0. PSP was essentially a stripped-down version of SCC designed for upstream Kubernetes. Its creation predated the formal Kubernetes Enhancements Proposal (KEP) process, making its early design history difficult to track. However, archives show that the final design proposal was created after initial code merges had already begun.

The roots of PSP were added through a series of pull requests starting in 2015. Before PSP existed, Kubernetes 1.0, released on July 10, 2015, lacked mechanisms to restrict security contexts beyond an alpha-quality plugin called SecurityContextDeny. The first PSP object, based on OpenShift’s SCC, merged into upstream Kubernetes in February 2016 after nine months of discussion. The admission controller followed in May 2016, with authorization mechanisms added later that year to allow different policies for different users.

Despite its intentions, PSP never graduated to stable status. It suffered from a flawed authorization model, deployment difficulties, and an inconsistent API. As a result, the Kubernetes community decided to remove it entirely in v1.25. It has been replaced by Pod Security Admission, a new in-tree plugin that enforces Pod Security Standards at the namespace level.

How it works

PodSecurityPolicy functioned as a specialized admission control plugin that provided fine-grained permissions on pod security fields. It aimed to decouple low-level Linux security decisions from the deployment process, allowing cluster administrators to set secure defaults without requiring every user to understand complex security primitives. The system relied on mutation and validation to enforce rules such as running as non-root or restricting privilege escalation.

However, PSP operated on a fail-closed basis. If no policy existed, all pods were denied. This made it difficult to enable by default, as administrators had to create policies for every workload before turning the feature on. There was no audit mode to identify which pods would fail under new policies, leading to frequent breakage and insufficient test coverage. Additionally, the API grew inconsistent over time as it accommodated niche use cases, making it hard to compose with other admission controllers.

The replacement, Pod Security Admission, simplifies this model by enforcing three predefined Pod Security Standards: Privileged, Baseline, and Restricted. Privileged is unrestricted, Baseline allows default configurations, and Restricted enforces security best practices. This approach removes the need for deep security knowledge for most users and provides a stable, namespace-level enforcement mechanism that is easier to adopt and maintain.

Key details

• PodSecurityPolicy was removed in Kubernetes v1.25 after being deprecated in v1.21.
• PSP originated from OpenShift’s SecurityContextConstraints and merged into Kubernetes in February 2016.
• The feature failed to reach stable status due to a flawed authorization model and deployment complexity.
• PSP operated on a fail-closed basis, requiring policies for all workloads before enabling.
• Pod Security Admission replaces PSP with three standards: Privileged, Baseline, and Restricted.
• The new admission controller is stable in Kubernetes v1.25 and operates at the namespace level.

Why it matters

For software engineers and platform teams, understanding the shift from PSP to Pod Security Admission is critical for maintaining secure clusters. PSP required significant expertise in Linux security primitives and careful management of policies to avoid breaking deployments. Its removal signals a move toward simpler, more opinionated security defaults that are easier to implement and less prone to configuration errors.

The new Pod Security Standards provide a clear path for securing workloads without the overhead of managing complex, custom policies. By focusing on three distinct levels of restriction, Kubernetes makes it easier for developers to adopt security best practices without needing deep knowledge of underlying security mechanisms. This change reduces the risk of misconfiguration and improves the overall security posture of Kubernetes clusters.

What you can do

• Upgrade your clusters to Kubernetes v1.25 or later to use the stable Pod Security Admission controller.
• Review your existing workloads to ensure they comply with the Baseline or Restricted Pod Security Standards.
• Replace any remaining PodSecurityPolicy objects with namespace-level labels that enforce the desired security standard.
• Use the audit mode available in earlier versions to identify pods that would fail under the new standards before enforcing them.
• Consult the Kubernetes documentation for hands-on tutorials on implementing Pod Security Admission.
• For sophisticated use cases not covered by the built-in standards, evaluate third-party admission controllers that can complement Pod Security Admission.