Container Security
A Kubernetes Pod Security Policy Alternative
A quick look at the deprecation of Kubernetes Pod Security Policy and how to ensure your clusters are protected going forward.
Using Kubernetes as your go-to container-orchestration system can have a lot of benefits, including more control for developers and operations staff. However, more control can result in more security risks. What if someone deploys an insecure resource in your cluster? How long would it take for you to notice?
This is where time of deployment security comes into play. Applying security policies to what can or can’t be deployed in your cluster helps you regain security for your cluster. In this blog, we will discuss how the Kubernetes Pod Security Policy feature fits into your clusters security picture, what’s being removed, and similar security options to consider for the future.
What is Kubernetes Pod Security Policy?
The Kubernetes Pod Security Policy (PSP) is a built-in admission controller that allows cluster administrators to control the deployment of security-sensitive aspects of a Kubernetes Pod. The feature was introduced in the early days of Kubernetes and supports 16 different Pod security controls. Its main benefit is being able to decouple security decisions from deployment, enabling security or operations teams to control them.
For example, the following PSP can be used to ensure a container is not allowed to escalate to root permissions.
Check out the Kubernetes documentation for more information on Pod Security Policies.
Why is it being removed?
The main concern with the existing PSP feature is its usability problems. This is also the main reason why the feature never exited Kubernetes’ beta program.
Some of the problems with the PSP feature include:
- Flawed authorisation model: A PSP is bound to the requesting user or the Pod’s service account. This makes it difficult to know which is bound to the policy.
- Roll out: PSP fails closed when there is no policy, therefore with no PSPs, all pods are denied. This means roll-out is an all-or-nothing approach; you must either create policies for all existing resources or deny all pods you missed.
- Inconsistent API: The API for PSPs has evolved and become more inconsistent, meaning you often need several requests for certain use cases, or some use cases just aren’t supported due to the relationship between PSPs and Pods.
When is it being removed?
PSP is being deprecated in Kubernetes 1.21, which was released at the beginning of April 2021. According to Kubernetes, the deprecation of the PSP feature will follow Kubernetes deprecation policy, meaning that although the PSP feature is marked as deprecated in Kubernetes 1.21, it will be fully functional for several releases. The Kubernetes sig-auth group has announced that they plan to fully remove the feature in Kubernetes 1.25.
How can I get the same protection?
Create your own Kubernetes admission controller
Since PSPs were implemented using a built-in admission controller in Kubernetes, it is possible to reproduce its behaviour with your own custom admission controller. The Kubernetes blog is a good guide for getting started with a custom admission controller. This option gives you full control and flexibility over your protection, however it also requires you to implement a fully custom solution using Kubernetes admission webhooks.
Open Policy Agent Gatekeeper
Open Policy Agent (OPA) is a well-known general-purpose policy engine that enables policy enforcement across the entire stack. OPA is maintained by the Cloud Native Computing Foundation (CNCF) and contains several projects for enforcing policies in your Kubernetes environment. If you are looking for a quick way to enforce basic security policies on your cluster, then OPA Gatekeeper may be the tool for you. It can also be used to develop and enforce policies to help strengthen your environment’s security and governance posture. Gatekeeper has done the work of implementing a Kubernetes admission webhook and bridging the gap between the Kubernetes API server and OPA. However, since Gatekeeper is installed directly in the cluster and isn’t a hosted service, it lacks the ability to configure policies from a common interface or the ability to use external inputs such as image scan results.
Introducing Trend Micro Cloud One™ – Container Security
Container Security is one of seven security solutions that make up the Trend Micro Cloud One™ security services platform. In addition to protecting build and runtime stages of the container lifecycle, Container Security can protect the deployment stage by providing a ready-built admission controller to block or log deployments based on Kubernetes configuration settings or even image scan findings. This allows users to create policies that exceed coverage previously provided by PSPs. In addition, the solution gives you fine grained control of these policies across namespaces through an easy-to-use web-based console.
Using a SaaS-based solution like Container Security allows for easier re-use of policies across clusters, ability to continuously verify policy compliance during runtime, and view deployment security events using web interface or programmatically, using integrated APIs. This extra visibility into your clusters, which is not easily achieved with currently available open source tooling, is crucial for understanding what is happening inside your production clusters.
See the Container Security documentation to learn more and get started with a free, 30-day trial.
