Back in December, the Kubernetes Auth Special Interest Group (AKA sig-auth) announced its decision to deprecate the pod security policy (PSP) in Kubernetes version 1.21 and to remove the API completely at version 1.25. This decision could leave many Kubernetes users at risk of being exposed to various exploits. Adversaries may utilize the lack of such policy to run privileged pods, create pods on host namespaces or networks and much more. Prisma Cloud customers can mitigate PSP deprecation through the built-in admission controller which utilizes Open Policy Agent (OPA) rules.
Some Background
Pods are the most basic building block of Kubernetes clusters. Since pods are usually the most exposed surface to adversarial attacks, ensuring the security of pods is of the utmost importance. In order to mitigate these concerns, Kubernetes teams decided to provide a built-in mechanism to help users apply a fine-grained security policy to their pods.
What Is Pod Security Policy?
The official definition from Kubernetes documentation says “A Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for the related fields.“
For example, with a PSP defined you can decide:
- Can a pod be created with a privileged container?
- Can a pod that mounts a sensitive host path be created?
- Can a pod that escalates root privileges be created?
- Can a pod be created with host filesystem usages?
Why Is It Being Removed?
The PSP feature was introduced in Kubernetes 1.3 and it has been stuck in beta ever since. The reasons for PSP deprecation are some fundamental flaws in its design:
PSPs are bound with a dual model
When creating a PSP, it is bound to the subject of the pod being created. Meaning, policies are bound to the requesting user OR the pod’s service account – this is a dual model. This model weakens security since it’s hard to determine which is the subject bound to the policy.
PSPs do not apply to all Kubernetes resources
As the name suggests, the PSP is relevant only for pod security. There have been security issues, such as the ability to bypass hostPath mount restrictions, that couldn’t be solved with PSP simply because they were out of its scope. As Kubernetes scales, it would be harder to determine which resource is part of the PSP and which is not.
PSP admission fail close mode
When enabled, in the absence of a policy, the PSP admission control would fail close. This means that pods won’t start until you cover all the subjects bound to the policy. Therefore, the PSP admission control can never be enabled by default. This also makes it much more difficult to have complete test coverage for the policy.
The main question at the basis of the future of this feature was: Does Kubernetes actually need a built-in mechanism for pod admission policy? Now that you know that PSP deprecation is happening, the answer is simply no. But fear not – we’ve got you covered!
Palo Alto Networks Got Your Back
Prisma Cloud customers benefit from the built-in admission control feature. This feature, based on Open Policy Agent (OPA), can mitigate PSP deprecation – and do much more (see “Mitigating Non-Pod Resources” section below).
As opposed to the PSP setup, with Prisma Cloud you can simply enable the feature and compose the policy rules via our UI:
Each of these rules is implemented with the Rego syntax and you can decide to alert/block or allow any rule. This feature is also cloud-agnostic, meaning, you can use the same solution regardless of your Kubernetes deployment infrastructure.
The output of the alert/block operations are all visible through a dedicated event viewer which adds all relevant information related to the blocked request:
Built-In Set Of Recommended Rules
We have created a set of rules delivered out-of-the-box. Some of these predefined rules implement specific sections of the Kubernetes CIS benchmark.
Here are some examples of our current set of predefined rules:
- Creation of a privileged pod
- Pod created in a host process ID namespace
- Pod created on a host IPC namespace
- Pod created on a host network
As you can see, some of these rules already implement conditions defined as part of the PSP.
Composing PSP To Rego Rules
You can also take existing PSP conditions and compose them into a Rego syntax and have them ready to block or alert in no time.
For example, PSP enables you to avoid creating pods that allow privilege escalation:
AllowPrivilegeEscalation - Gates whether or not a user is allowed to set the security context of a container to allowPrivilegeEscalation=true. This defaults to allowed so as to not break setuid binaries. Setting it to false ensures that no child process of a container can gain more privileges than its parent.
Let’s say we want to block any container that allows privilege escalation. In order to enforce such a rule, we need to examine each review request in the following order:
- Validate that the review request is for creating an object
- Validate that the request kind is of a pod
- Validate that the resource being created is a pod
- Validate the security context of each container being created - if this context sets the allowPrivilegeEscalation flag to true for one of its containers - block it
Let’s see how this looks using the Rego syntax:
As required, the admission rule effect is set to block and the rule is ready to be applied.
After applying the rule, let’s try to create a pod that defines privilege escalation to one of its containers:
Mitigating Non-Pod Resources
In December 2020, Unit 42 Cloud Threat Researchers published an article on how to protect against an unfixed Kubernetes man-in-the-middle vulnerability (CVE-2020-8554). The mitigation of this vulnerability also utilizes our admission control feature. This is possible because the admission control is not limited to specific resource types.
Filling Kubernetes Security Gaps
PSP had good intentions to prevent privilege escalation attacks, and therefore its deprecation and future removal will leave a gap for some Kubernetes operators. The Prisma Cloud integration with OPA allows us to protect customers from overly permissive policies in Kubernetes. This capability, along with our comprehensive suite of cloud native security tools, helps our customers maintain their security posture as Kubernetes scales and more vulnerable components are discovered.
If you’d like to see our solution for PSP deprecation and other features in action, reach out to request a personalized demo.