Last updated Sept 8, 2022

As of v1.25, Kubernetes is completely removing Pod Security Policies (PSPs). They are replacing it with a controller called Pod Security Admission, which uses formal controls called Pod Security Standards (PSS). It’s new as of v1.22 and automatically enabled in Kubernetes v1.23. 

In this post, we will discuss how this came to be and why you should consider using Kyverno to address pod and other configuration security concerns for your clusters.

Pod Security Policies

Pods are the basic unit of execution and control in Kubernetes. A Pod is composed of one or more containers, typically a single “application” container and optionally one or more helper containers for initialization or auxiliary functions such as periodically fetching data (like secrets) from an external source.

Each Pod has a securityContext that controls runtime security configurations for the pod. The securityContext contains fields that manage the pod’s runtime group and user settings, SELinux options, Seccomp (Linux kernel secure computing mode) profiles, and kernel parameters using Sysctls. 

Additionally, each container in a pod can also specify a securityContext to override pod-wide settings and define additional security settings such as whether the container runs in a privileged mode (basically runs with root access), whether a container process can gain more privileges than its parent process, the additional Linux kernel capabilities the container can use, whether the container root file system is read-only, and if the container has visibility to other processes via the /proc filesystem.

These settings are very powerful and allow a lot of flexibility. However, they can also be dangerous. Misconfigurations, or lack of proper enforcement of security best practices, can lead to exploits where a bad pod is used to gain access to container hosts or the control plane.

 Pod Security Policies (PSPs) were designed to control security related settings for a pod by defining a set of conditions that the pod must pass for it to run. Otherwise, if a pod does not comply, the pod is rejected. For example, a PSP can prevent running a pod as a root user.

Why are Pod Security Policies Being Deprecated? 

PSPs have been stuck in beta as they are difficult, if not impossible, to implement and manage in real-world scenarios. When enabled, pod security policies can immediately impact all workloads and so can be a non-starter for clusters with production workloads. Role bindings are used to map PSPs to workloads, but this quickly gets confusing as most pods are run by pod controllers and not users, and PSPs use a dual permission model. And, If there are multiple pod security policies that a pod has access to, the one that applies is determined by alphabetical order, which may lead to unintended consequences.  PSPs also are focused on pod security and do not cover other aspects of configuration security. And, PSPs are focused on Linux runtimes and do not support other platforms like Windows.

Due to these challenges, pod security policies are being deprecated in version Kubernetes version 1.21 and will be removed in version 1.25 of Kubernetes. For more information, refer to the Kubernetes blog post Blog: PodSecurityPolicy Deprecation: Past, Present, and Future by Tabitha Sable, co-chair of the Kubernetes SIG Security.

What are Pod Security Standards?

The Kubernetes Pod Security Standards (PSS) definition provides recommended security profiles to use for pod security. PSPs and its replacement, Pod Security Admission, are implementations of Pod Security Standards. 

Currently three levels are defined in PSS:

1. Privileged: not secure and allows all settings.
2. Baseline: a minimally restrictive policy that prevents known privilege escalations. This level contains nine (9) controls to manage pod configuration security settings:
   1. Host Namespaces
   2. Privileged Containers
   3. Capabilities
   4. HostPath Volumes
   5. Host Ports
   6. AppArmor
   7. SELinux
   8. /proc mount type
   9. Sysctls
3. Restricted: a heavily restrictive policy that enforces best practices. This level includes all controls from the baseline profile and contains five (5) additional controls to further harden the pod configuration:
   1. Volume Types
   2. Privilege Escalation
   3. Running as Non-root
   4. Not-root Groups
   5. Seccomp

Pod Security Standards provide a common definition for pod security that is decoupled from any implementation. This also allows external policy engines like Kyverno and OPA/Gatekeeper to implement Pod Security Standards and provide additional capabilities that will not be supported by the in-tree replacement.

Pod Security Admission

Pod Security Admission is the latest implementation of Pod Security Standards. It’s new as of v1.22 and automatically enabled in Kubernetes v1.23. While Pod Security admission addresses some security concerns, it has many drawbacks:

1. Only works on Pods: production Kubernetes needs controls and guarantees on things beyond just Pods.
2. Cluster-wide configuration is hard: it cannot apply controls to clusters without special configuration, which requires API and control plane access.
3. One-size-fits all approach: you cannot be selective about which PSS controls to enforce; there are very limited exemptions.
4. Audits are difficult: logs are not enabled by default and, once they are, audits require a lot of digging.
5. No DevOps pipeline: PSA is ingrained into the Kubernetes control plane, which means you cannot use a standalone utility to test a given resource.

Not sure if your Pods are secure? Use this 2-minute test to see if your cluster meets the Kubernetes Pod Security Standards.

Kyverno Open Source Policy Engine

Kyverno (a Greek word for “govern”) is a policy engine that was built for Kubernetes and uses Kubernetes Custom Resources to define policies. Kyverno was created by Nirmata and is a CNCF Sandbox project.

Kyverno runs as an admission controller. This means that all Kubernetes API requests can be validated or mutated by Kyverno policies. When Kyverno installs itself in your cluster, it will create a ValidatingWebhookConfiguration and a MutatingWebhookConfiguration to apply policies to API requests.

Kyverno policies can validate, mutate, and generate Kubernetes resource configurations. The Kyverno policy library has a full implementation of Pod Security Standards and several other policies to help secure configurations and apply best practices.

Since Kyverno is native to Kubernetes, the project will align with the PSP replacement as the implementation evolves. Hence with Kyverno, you can immediately start auditing or enforcing Pod Security Standards and then later decide if you should enable the built-in PSP replacement when it’s ready and continue using Kyverno for additional policies. 

Installing Kyverno for Better Pod Security

Getting started with Kyverno is easy! Let’s install Kyverno using the Helm chart:

Add the Kyverno Helm repository:

helm repo add kyverno https://kyverno.github.io/kyverno/

Pull the latest chart information:

helm repo update

Install Kyverno:

helm install kyverno kyverno/kyverno \
    --namespace kyverno --create-namespace \
    --set podSecurityStandard=restricted \
    --set validationFailureAction=enforce

Once Kyverno is installed you should see the following output from Helm:

NAME: kyverno
LAST DEPLOYED: Mon May 24 01:59:49 2021
NAMESPACE: kyverno
STATUS: deployed
REVISION: 1
NOTES:
Thank you for installing kyverno v1.3.6 �

Your release is named kyverno.

We have installed the "restricted" profile of Pod Security Standards and set them in enforce mode.

Visit https://kyverno.io/policies/ to find more sample policies.

The Kyverno Helm chart includes policies that implement Pod Security Standards. By default (if no parameters are set), the Helm chart will install the “baseline” profile and the policies will be installed in “audit” mode. Here we set the parameter “podSecurityStandard” to the value “restricted” and also set the parameters “validationFailureAction” to the value “enforce”. These settings will block any pods or workloads that do not conform to the restricted profile level in the Pod Security Standards. 

Once installed, you can view and customize Kyverno policies using kubectl (cpol is the short name for ClusterPolicy):

λ kubectl get cpol
NAME BACKGROUND ACTION
deny-privilege-escalation true enforce
disallow-add-capabilities true enforce
disallow-host-namespaces true enforce
disallow-host-path true enforce
disallow-host-ports true enforce
disallow-privileged-containers true enforce
disallow-selinux true enforce
require-default-proc-mount true enforce
require-non-root-groups true enforce
require-run-as-non-root true enforce
restrict-apparmor-profiles true enforce
restrict-seccomp true enforce
restrict-sysctls true enforce
restrict-volume-types true enforce

Conclusion

Kyverno is a powerful and easy to use policy engine designed for Kubernetes, that does not require learning a new language to write policies, and adopting new tools to manage policies. 

Kyverno already supports the Kubernetes Pod Security Standards and serves as an excellent alternative to Pod Security Admission. If you are currently not using PSPs, this makes Kyverno a safe bet to get started. If you are currently using PSPs, you can easily migrate to Kyverno using the equivalent pod security policies and hence prepare for the deprecation of PSPs. 

In addition, you can also use Kyverno’s powerful generate policies to automate workflows to generate default resources and fine-grained configurations for users and workloads, and enable secure self-service for users. 

Learn more about Kyerno and our policy management solutions here or start a free trial of Nirmata today.

Still have questions? Nirmata has answers! Please reach-out to us here to have a conversation on Kyverno and pod security standards for DevSecOps needs.