PodSecurityPolicy: From Inception to Deprecation – A Retrospective

The PodSecurityPolicy (PSP) was removed with Kubernetes v1.25. This decision was previously announced in the blog post PodSecurityPolicy Deprecation: Past, Present, and Future. In this article, we take a look at the inception and evolution of the PSP, explain why it never became stable, and show why it was replaced by the Pod Security Admission Control.

The Inception of PodSecurityPolicy

The PodSecurityPolicy has its roots in the SecurityContextConstraints (SCC) of OpenShift, which were implemented in the first version of the Red Hat OpenShift Container Platform, even before the release of Kubernetes 1.0. The PSP was a simplified version of the SCC.

The exact history of the PodSecurityPolicy is difficult to trace, as it was mainly added before the Kubernetes Enhancements Proposal (KEP) process, when design proposals existed in a different form. However, the archive of the final design proposal is still available. After the initial pull requests were merged, a KEP number five was also created.

Before the implementation of the first code that created the PSP, two important pull requests were integrated into Kubernetes: a SecurityContext subresource that defined new fields for containers in Pods, and the first iteration of the ServiceAccount API.

Kubernetes 1.0 was released on July 10, 2015, without mechanisms to restrict the security context and sensitive options for workloads, apart from an alpha-quality SecurityContextDeny Admission Plugin (then known as scdeny). The SecurityContextDeny Plugin is still present in Kubernetes today (as an alpha feature) and creates an admission controller that prevents the use of certain fields in the security context.

The roots of the PodSecurityPolicy were added with the first pull request for security policies, which included the design proposal with the new PSP object, based on the SCC. It was a long discussion of nine months, with much feedback from OpenShift’s SCC, many rebases, and the renaming to PodSecurityPolicy, which was finally integrated into Kubernetes in February 2016. Once the PSP object was created, the next step was to add an admission controller that could enforce these policies. The first step was to add the admission without considering users or groups. A specific issue to bring the PodSecurityPolicy to a usable state was added to track progress, and an initial version of the admission controller was merged in the pull request named PSP Admission in May 2016. About two months later, Kubernetes 1.3 was released.

The path to the deprecation of the PodSecurityPolicy is an important step that shows how security policies in Kubernetes can evolve. For developers and DevOps teams, this means they need to adapt to new security mechanisms that will simplify and improve the management and enforcement of security policies. At ayedo, we are happy to assist you in implementing these new security strategies!

Source: Kubernetes Blog