Aqua Blog

Kubernetes Pod Security Policy Deprecation: All You Need to Know

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
pod security policy resource

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:

PSS policy PSS control Mapping to PSP control
Baseline Host Namespaces Usage of host namespaces

Usage of host networking and ports

Privileged Containers Running of privileged containers
Capabilities Linux capabilities
HostPath Volumes Usage of the host filesystem
Host Ports Not covered in PSP
AppArmor (optional) The AppArmor profile used by containers
SELinux (optional) The SELinux context of the container
/proc Mount Type The Allowed Proc Mount types for the container
Sysctls The sysctl profile used by containers
Restricted Volume Types Usage of volume types

Allow specific FlexVolume drivers

Requiring the use of a read-only root file system

Privilege Escalation Restricting escalation to root privileges
Running as Non-root Not covered in PSP
Non-root groups Allocating an FSGroup that owns the Pod’s volumes

The user and group IDs of the container

Seccomp The seccomp profile used by containers

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:

Helm chart Pod controller PSS – baseline PSS – restricted
nginx-stable/Nginx-ingress:0.7.1 Deployment Fail with one control:
Fail with two controls:
Privilege Escalation,
Running as Non-root
stable/mysql:1.6.7 Deployment Pass Fails with one control:
Running as Non-root
stable/kibana:3.2.8 Deployment Pass Fails with one control:
Running as Non-root
stable/prometheus:11.12.1 Deployment Pass Pass
elastic/elasticsearch:7.10.2 StatefulSet Fail with one control:
Privileged Containers
stable/postgesql:8.6.4 StatefulSet Pass Fails with one control:
Running as Non-root
stable/redis:10.5.7 StatefulSet Pass Fails with one control:
Running as Non-root
stable/memcached:3.2.3 StatefulSet Pass Fails with one control:
Running as Non-root
bitnami/cassandra:7.1.5 StatefulSet Pass Fails with one control:
Running as Non-root

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.


Amit Bismut
Amit is a product manager at Aqua. As part of the Aqua product team, his work focuses on Kubernetes and container security in the Cloud Native ecosystem. When he isn't at work, he enjoys writing music and playing in a rock-blues band as a guitar player.