Creator: Mahé Tardy (Quarkslab)
The PodSecurityPolicy (PSP) admission controller has been eradicated, as of
Kubernetes v1.25. Its deprecation was announced and in-depth in the site put up
PodSecurityPolicy Deprecation: Previous, Existing, and Future,
posted for the Kubernetes v1.21 release.
This report aims to present historic context on the beginning and evolution of
PSP, describe why the element hardly ever manufactured it to steady, and display why it was
taken off and replaced by Pod Security admission command.
PodSecurityPolicy, like other specialized admission regulate plugins, provided
fine-grained permissions on specific fields regarding the pod security configurations
as a developed-in plan API. It acknowledged that cluster administrators and
cluster buyers are normally not the similar people, and that creating workloads in
the variety of a Pod or any resource that will produce a Pod really should not equivalent being
“root on the cluster”. It could also inspire ideal practices by configuring
additional safe defaults by means of mutation and decoupling reduced-stage Linux security
choices from the deployment procedure.
The delivery of PodSecurityPolicy
PodSecurityPolicy originated from OpenShift’s SecurityContextConstraints
(SCC) that were in the extremely initial release of the Pink Hat OpenShift Container System,
even right before Kubernetes 1.. PSP was a stripped-down edition of the SCC.
The origin of the creation of PodSecurityPolicy is complicated to keep track of, notably
due to the fact it was predominantly added ahead of Kubernetes Enhancements Proposal (KEP)
system, when design proposals were nonetheless a factor. In fact, the archive of the remaining
design proposal
is even now available. Nonetheless, a KEP concern quantity 5
was created right after the 1st pull requests were merged.
Right before incorporating the 1st piece of code that developed PSP, two key pull
requests had been merged into Kubernetes, a SecurityContext subresource
that described new fields on pods’ containers, and the first iteration of the ServiceAccount
API.
Kubernetes 1. was launched on 10 July 2015 without the need of any mechanism to prohibit the
stability context and sensitive alternatives of workloads, other than an alpha-high-quality
SecurityContextDeny admission plugin (then recognized as scdeny).
The SecurityContextDeny plugin
is however in Kubernetes nowadays (as an alpha function) and makes an admission controller that
stops the use of some fields in the safety context.
The roots of the PodSecurityPolicy were extra with
the extremely 1st pull request on security plan,
which extra the design and style proposal with the new PSP object, primarily based on the SCC (Stability Context Constraints). It
was a extended discussion of nine months, with back again and forth from OpenShift’s SCC,
quite a few rebases, and the rename to PodSecurityPolicy that lastly produced it to
upstream Kubernetes in February 2016. Now that the PSP object
had been produced, the up coming phase was to add an admission controller that could enforce
these policies. The first step was to include the admission
with no taking into account the consumers or teams.
A unique challenge to convey PodSecurityPolicy to a usable point out
was added to keep observe of the development and a very first variation of the admission
controller was merged in pull request named PSP admission
in May possibly 2016. Then all around two months later on, Kubernetes 1.3 was produced.
Below is a timeline that recaps the principal pull requests of the birth of the
PodSecurityPolicy and its admission controller with 1. and 1.3 releases as
reference points.
Following that, the PSP admission controller was enhanced by adding what was originally
remaining aside. The authorization system,
merged in early November 2016 authorized directors to use multiple guidelines
in a cluster to grant diverse levels of accessibility for distinctive types of customers.
Later on, a pull ask for
merged in October 2017 fixed a style issue
on buying PodSecurityPolicies among mutating and alphabetical purchase, and continued to
build the PSP admission as we know it. Right after that, several enhancements and fixes
adopted to create the PodSecurityPolicy attribute of the latest Kubernetes releases.
The increase of Pod Stability Admission
Even with the very important difficulty it was seeking to solve, PodSecurityPolicy offered
some important flaws:
- Flawed authorization model – users can develop a pod if they have the
use verb on the PSP that will allow that pod or the pod’s service account has
the use permission on the permitting PSP. - Tough to roll out – PSP fail-shut. That is, in the absence of a coverage,
all pods are denied. It typically implies that it are not able to be enabled by default and
that consumers have to insert PSPs for all workloads prior to enabling the characteristic,
consequently supplying no audit method to explore which pods would not be allowed by
the new plan. The choose-in design also leads to inadequate check coverage and
frequent breakage owing to cross-aspect incompatibility. And not like RBAC,
there was no solid culture of transport PSP manifests with projects. - Inconsistent unbounded API – the API has grown with plenty of
inconsistencies notably because of several requests for specialized niche use instances: e.g.
labels, scheduling, wonderful-grained quantity controls, etc. It has inadequate
composability with a weak prioritization model, major to unexpected
mutation priority. It made it actually tough to incorporate PSP with other
3rd-party admission controllers. - Involve security knowledge – helpful utilization nevertheless necessitates an
comprehension of Linux stability primitives. e.g. MustRunAsNonRoot +
AllowPrivilegeEscalation.
The practical experience with PodSecurityPolicy concluded that most consumers care for two or a few
policies, which led to the creation of the Pod Stability Specifications,
that define three policies:
- Privileged – unrestricted policy.
- Baseline – minimally restrictive coverage, making it possible for the default pod
configuration. - Restricted – stability very best apply plan.
The alternative for PSP, the new Pod Protection Admission
is an in-tree, steady for Kubernetes v1.25, admission plugin to implement these
standards at the namespace degree. It tends to make it a lot easier to implement primary pod
protection with no deep security knowledge. For much more refined use circumstances, you
may well require a 3rd-celebration answer that can be easily combined with Pod Stability
Admission.
What is following
For additional particulars on the SIG Auth procedures, covering PodSecurityPolicy removal and
generation of Pod Safety admission, the
SIG auth update at KubeCon NA 2019
and the PodSecurityPolicy Alternative: Earlier, Current, and Potential
presentation at KubeCon NA 2021 records are available.
Significantly on the PSP removal, the
PodSecurityPolicy Deprecation: Previous, Existing, and Future
blog site put up is nevertheless exact.
And for the new Pod Safety admission,
documentation is available.
In addition, the weblog put up
Kubernetes 1.23: Pod Security Graduates to Beta
alongside with the KubeCon EU 2022 presentation
The Hitchhiker’s Tutorial to Pod Safety
give good hands-on tutorials to find out.