|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: "PodSecurityPolicy: The Historical Context" |
| 4 | +date: 2022-08-23T15:00:00-0800 |
| 5 | +slug: podsecuritypolicy-the-historical-context |
| 6 | +--- |
| 7 | + |
| 8 | +**Author:** Mahé Tardy (Quarkslab) |
| 9 | + |
| 10 | +The PodSecurityPolicy (PSP) admission controller has been removed, as of |
| 11 | +Kubernetes v1.25. Its deprecation was announced and detailed in the blog post |
| 12 | +[PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/), |
| 13 | +published for the Kubernetes v1.21 release. |
| 14 | + |
| 15 | +This article aims to provide historical context on the birth and evolution of |
| 16 | +PSP, explain why the feature never made it to stable, and show why it was |
| 17 | +removed and replaced by Pod Security admission control. |
| 18 | + |
| 19 | +PodSecurityPolicy, like other specialized admission control plugins, provided |
| 20 | +fine-grained permissions on specific fields concerning the pod security settings |
| 21 | +as a built-in policy API. It acknowledged that cluster administrators and |
| 22 | +cluster users are usually not the same people, and that creating workloads in |
| 23 | +the form of a Pod or any resource that will create a Pod should not equal being |
| 24 | +"root on the cluster". It could also encourage best practices by configuring |
| 25 | +more secure defaults through mutation and decoupling low-level Linux security |
| 26 | +decisions from the deployment process. |
| 27 | + |
| 28 | +## The birth of PodSecurityPolicy |
| 29 | + |
| 30 | +PodSecurityPolicy originated from OpenShift's SecurityContextConstraints |
| 31 | +(SCC) that were in the very first release of the Red Hat OpenShift Container Platform, |
| 32 | +even before Kubernetes 1.0. PSP was a stripped-down version of the SCC. |
| 33 | + |
| 34 | +The origin of the creation of PodSecurityPolicy is difficult to track, notably |
| 35 | +because it was mainly added before Kubernetes Enhancements Proposal (KEP) |
| 36 | +process, when design proposals were still a thing. Indeed, the archive of the final |
| 37 | +[design proposal](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/pod-security-policy.md) |
| 38 | +is still available. Nevertheless, a [KEP issue number five](https://github.com/kubernetes/enhancements/issues/5) |
| 39 | +was created after the first pull requests were merged. |
| 40 | + |
| 41 | +Before adding the first piece of code that created PSP, two main pull |
| 42 | +requests were merged into Kubernetes, a [`SecurityContext` subresource](https://github.com/kubernetes/kubernetes/pull/7343) |
| 43 | +that defined new fields on pods' containers, and the first iteration of the [ServiceAccount](https://github.com/kubernetes/kubernetes/pull/7101) |
| 44 | +API. |
| 45 | + |
| 46 | +Kubernetes 1.0 was released on 10 July 2015 without any mechanism to restrict the |
| 47 | +security context and sensitive options of workloads, other than an alpha-quality |
| 48 | +SecurityContextDeny admission plugin (then known as `scdeny`). |
| 49 | +The [SecurityContextDeny plugin](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#securitycontextdeny) |
| 50 | +is still in Kubernetes today (as an alpha feature) and creates an admission controller that |
| 51 | +prevents the usage of some fields in the security context. |
| 52 | + |
| 53 | +The roots of the PodSecurityPolicy were added with |
| 54 | +[the very first pull request on security policy](https://github.com/kubernetes/kubernetes/pull/7893), |
| 55 | +which added the design proposal with the new PSP object, based on the SCC (Security Context Constraints). It |
| 56 | +was a long discussion of nine months, with back and forth from OpenShift's SCC, |
| 57 | +many rebases, and the rename to PodSecurityPolicy that finally made it to |
| 58 | +upstream Kubernetes in February 2016. Now that the PSP object |
| 59 | +had been created, the next step was to add an admission controller that could enforce |
| 60 | +these policies. The first step was to add the admission |
| 61 | +[without taking into account the users or groups](https://github.com/kubernetes/kubernetes/pull/7893#issuecomment-180410539). |
| 62 | +A specific [issue to bring PodSecurityPolicy to a usable state](https://github.com/kubernetes/kubernetes/issues/23217) |
| 63 | +was added to keep track of the progress and a first version of the admission |
| 64 | +controller was merged in [pull request named PSP admission](https://github.com/kubernetes/kubernetes/pull/24600) |
| 65 | +in May 2016. Then around two months later, Kubernetes 1.3 was released. |
| 66 | + |
| 67 | +Here is a timeline that recaps the main pull requests of the birth of the |
| 68 | +PodSecurityPolicy and its admission controller with 1.0 and 1.3 releases as |
| 69 | +reference points. |
| 70 | + |
| 71 | +{{< figure src="./timeline.svg" alt="Timeline of the PodSecurityPolicy creation pull requests" >}} |
| 72 | + |
| 73 | +After that, the PSP admission controller was enhanced by adding what was initially |
| 74 | +left aside. [The authorization mechanism](https://github.com/kubernetes/kubernetes/pull/33080), |
| 75 | +merged in early November 2016 allowed administrators to use multiple policies |
| 76 | +in a cluster to grant different levels of access for different types of users. |
| 77 | +Later, a [pull request](https://github.com/kubernetes/kubernetes/pull/52849) |
| 78 | +merged in October 2017 fixed [a design issue](https://github.com/kubernetes/kubernetes/issues/36184) |
| 79 | +on ordering PodSecurityPolicies between mutating and alphabetical order, and continued to |
| 80 | +build the PSP admission as we know it. After that, many improvements and fixes |
| 81 | +followed to build the PodSecurityPolicy feature of recent Kubernetes releases. |
| 82 | + |
| 83 | +## The rise of Pod Security Admission |
| 84 | + |
| 85 | +Despite the crucial issue it was trying to solve, PodSecurityPolicy presented |
| 86 | +some major flaws: |
| 87 | + |
| 88 | +- **Flawed authorization model** - users can create a pod if they have the |
| 89 | + **use** verb on the PSP that allows that pod or the pod's service account has |
| 90 | + the **use** permission on the allowing PSP. |
| 91 | +- **Difficult to roll out** - PSP fail-closed. That is, in the absence of a policy, |
| 92 | + all pods are denied. It mostly means that it cannot be enabled by default and |
| 93 | + that users have to add PSPs for all workloads before enabling the feature, |
| 94 | + thus providing no audit mode to discover which pods would not be allowed by |
| 95 | + the new policy. The opt-in model also leads to insufficient test coverage and |
| 96 | + frequent breakage due to cross-feature incompatibility. And unlike RBAC, |
| 97 | + there was no strong culture of shipping PSP manifests with projects. |
| 98 | +- **Inconsistent unbounded API** - the API has grown with lots of |
| 99 | + inconsistencies notably because of many requests for niche use cases: e.g. |
| 100 | + labels, scheduling, fine-grained volume controls, etc. It has poor |
| 101 | + composability with a weak prioritization model, leading to unexpected |
| 102 | + mutation priority. It made it really difficult to combine PSP with other |
| 103 | + third-party admission controllers. |
| 104 | +- **Require security knowledge** - effective usage still requires an |
| 105 | + understanding of Linux security primitives. e.g. MustRunAsNonRoot + |
| 106 | + AllowPrivilegeEscalation. |
| 107 | + |
| 108 | +The experience with PodSecurityPolicy concluded that most users care for two or three |
| 109 | +policies, which led to the creation of the [Pod Security Standards](/docs/concepts/security/pod-security-standards/), |
| 110 | +that define three policies: |
| 111 | +- **Privileged** - unrestricted policy. |
| 112 | +- **Baseline** - minimally restrictive policy, allowing the default pod |
| 113 | + configuration. |
| 114 | +- **Restricted** - security best practice policy. |
| 115 | + |
| 116 | +The replacement for PSP, the new [Pod Security Admission](/docs/concepts/security/pod-security-admission/) |
| 117 | +is an in-tree, stable for Kubernetes v1.25, admission plugin to enforce these |
| 118 | +standards at the namespace level. It makes it easier to enforce basic pod |
| 119 | +security without deep security knowledge. For more sophisticated use cases, you |
| 120 | +might need a third-party solution that can be easily combined with Pod Security |
| 121 | +Admission. |
| 122 | + |
| 123 | +## What's next |
| 124 | + |
| 125 | +For further details on the SIG Auth processes, covering PodSecurityPolicy removal and |
| 126 | +creation of Pod Security admission, the |
| 127 | +[SIG auth update at KubeCon NA 2019](https://www.youtube.com/watch?v=SFtHRmPuhEw) |
| 128 | +and the [PodSecurityPolicy Replacement: Past, Present, and Future](https://www.youtube.com/watch?v=HsRRmlTJpls) |
| 129 | +presentation at KubeCon NA 2021 records are available. |
| 130 | + |
| 131 | +Particularly on the PSP removal, the |
| 132 | +[PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) |
| 133 | +blog post is still accurate. |
| 134 | + |
| 135 | +And for the new Pod Security admission, |
| 136 | +[documentation is available](/docs/concepts/security/pod-security-admission/). |
| 137 | +In addition, the blog post |
| 138 | +[Kubernetes 1.23: Pod Security Graduates to Beta](/blog/2021/12/09/pod-security-admission-beta/) |
| 139 | +along with the KubeCon EU 2022 presentation |
| 140 | +[The Hitchhiker's Guide to Pod Security](https://www.youtube.com/watch?v=gcz5VsvOYmI) |
| 141 | +give great hands-on tutorials to learn. |
0 commit comments