Kubernetes Pod Security Policy Deprecation: All You Need to Know

To improve your Kubernetes security, you need to control and limit what pods can be created and deployed in your environment. For this, Kubernetes has provided a beta feature called Pod Security Policy (PSP), which soon will be deprecated and replaced with a standard called Pod Security Standards (PSS). In this blog, you’ll learn what this means for the security of your Kubernetes clusters, how you can migrate from PSP, and why using an OPA-based admission controller provides a great alternative.

Understanding Pod Security Policy (PSP)

The PSP feature has been available from the early days of Kubernetes and is designed to block misconfigured pods from being created on a given cluster. PSP supports 16 controls that check different Pod parameters such as:

• Running of privileged containers
• Usage of host namespaces
• Usage of host networking and ports

Example for pod security policy resource

The main drawbacks of the PSP are the lack of support for other resource types and a limited list of controls that don’t cover some container runtime-specific parameters. PSP is planned to be deprecated in 2021, and a better alternative exists to address the same need. The actual deprecation date has been recently extended from February 1st, 2021 to May 3rd, 2021 to allow vendors that use PSP, such as Azure, to prepare for the change. PSP is planned to be officially deprecated in Kubernetes version 1.21 and removed in version 1.25. According to the Kubernetes deprecation policy, older versions will stop getting support nine months after the deprecation of the feature.

Alternative tooling

So, what alternatives do you have? By using Kubernetes validating admission webhooks and OPA (Open Policy Agent), you can perform the same built-in checks that PSP provides and even more — for example, enforce checks on resources such as Services, CronJobs, etc., and evaluate ANY configuration in those resources rather than only the checks that PSP supports. Kubernetes mutating admission controllers can also address more use cases by modifying resources or patching them in different ways.

Kubernetes declarative management ability enables IaC (Infrastructure as Code). You can define the desired state of a resource by applying a manifest file (in YAML format) that describes how a resource should be created and configured. This approach encourages to perform the same workload configuration checks using OPA/Rego across different workload lifecycle points (e.g., code repository, CI/CD pipeline, pre-deployment, etc.).

Driven by this concept, many tools were created over the last year to assess Kubernetes resources against different configuration best practices, but which best practice should you follow?

The official Pod Security Standards (PSS)

PSS is the official standard that the Kubernetes project team has defined to address the security-related best practices for Pods. It includes two policies called “Baseline” and “Restricted,” where each of them has controls with a list of parameters and their permitted values in the Pod manifest. These policies can be enforced with any tool that supports validation of Rego/OPA checks.

For your convenience, the table below maps PSS controls to PSP controls and might come in handy if you plan to migrate from PSP:

Do common applications comply with PSS?

Although the workload configurations are not new in K8s, the awareness and security of common application aren’t as mature as we expect. In the table below, you can see how common Kubernetes Helm charts comply with PSS baseline and PSS restricted policies:

Tips for workload configuration security

1. If you rely on PSP, find an alternative
   Despite the PSP feature being in beta, organizations have been using it as part of their security policy, and some vendors even rely on it in their solution. If you don’t want to end up with an ineffective security model, we recommend replacing your PSP policy with an OPA-based admission controller as soon as possible.
2. Don’t use tools with hardcoded checks
   We believe in OPA/Rego and encourage you to use the tools that support it rather than tools with hardcoded checks. They allow you to avoid vendor lock-in, have the flexibility and power to check any field in a resource manifest, and manage identical checks across all stages of the resource lifecycle – from IaC to a running workload.
3. Start with PSS baseline
   PSS baseline policy provides a solid balance between security and potential friction, and requiring a minimal list of exceptions, it serves as a good starting point for workload security.
4. Don’t miss the pod controllers
   Most standards are referring to pods for simplicity. It is vital to perform the check on the pod controller (e.g., Deployment, CronJob, etc..) that holds the pod spec and will generate replicaSet and Pods on the cluster. This might be tricky for some parameters because they have different hierarchies in the resource manifest.For example, the “HostIPC” parameter has a different hierarchy on Pod, Deployment, and CrobJob:
   • Pods – “spec.HostIPC”
   • Deployment – “spec.template.spec.HostIPC”
   • CronJob – “spec.jobTemplate.spec.template.spec.HostIPC”
5. Don’t miss the container images
   PSS focuses on Pod misconfigurations that, in most cases, will prevent privilege escalation and potential lateral movement of an attacker in your environment. However, initial access risks on workloads usually come from vulnerable applications. To secure the image, you can do the following:
   • Check the image prefix to find if it is hosted in a trusted registry.
   • Commercial products typically provide an image scanning solution that is integrated with the workload configuration checks.

Contributing to the community

Up until now, the Pod Security Standards haven’t been available in the Rego implementation, which makes the migration from PSP more challenging and prevents the community from fully adopting OPA/Rego solutions. To help smooth the transition, we have decided to open our commercial Rego library to the community. Covering both PSP and PSS, as well as additional best practices, it’s the most comprehensive and well-maintained Rego library available, and you’re welcome to use it with any OPA/Rego tool you have.