Prepare Your Kubernetes Cluster for Pod Security Policy Deprecation
The Kubernetes community created a feature in v1.10 called Pod Security Policy (PSP) to control the security-related fields for pods defined in your Kubernetes cluster. Now that PodSecurityPolicy is being deprecated in Kubernetes v1.21, what should you do to secure your Kubernetes cluster? In this blog, we’ll learn a bit about PSP, explore why it’s being deprecated and how Open Policy Agent (OPA) can ease the migration from PSP.
What is Pod Security Policy?
A Kubernetes Pod Security Policy is a cluster-level resource that allows a cluster administrator to control security-sensitive aspects of the pod specification. A PodSecurityPolicy object defines a set of conditions that a pod must meet in order to be allowed into the cluster. It’s basically a built-in admission controller which enforces security policies on pods across a cluster.
PSP allows administrators to control 16 aspects of a pod such as Running of privileged containers in Kubernetes, Usage of host namespaces, Restricting escalation to root privileges.
One of the main reasons for deprecating PSP is the difficulty to correctly use them in the cluster. As most of us have found out by trial and error, if you have an existing cluster and you decide to turn on PSP without any policies, all your pods are denied entry into the cluster. The lack of auditing functionality makes it difficult to roll-out PSP in existing clusters.
Secondly, when a PSP resource is created, it does nothing. In order to use it, the requesting user or target pod’s service account must be authorized to use the policy, by allowing the use verb on the policy. Usually we see pods created indirectly as part of a Deployment, ReplicaSet, or other templated controller via the controller manager. We have all run into or can imagine the scenario where the user has permission to use the PSP, but what happens when they create a Deployment? In this case the Deployment and the resulting ReplicaSet get created but the pods will not get created since the ReplicaSet was not authorized to use the PSP. The error generated due to this is a bit confusing especially for new users, and thus makes debugging difficult.
Now that PSP is being deprecated in Kubernetes v1.21 and later removed in v1.25, how can you perform the same checks that PSP provides? With OPA as an admission controller you can not only perform all the controls that PSP defines but you can also enforce security policies for other Kubernetes resources. Let’s explore how to do that.
Kubernetes PSP migration with OPA
Here are some examples of how you can enforce PSP controls with OPA in a very simple and elegant manner. With PSP being deprecated, the Kubernetes team created a list of recommended best-practice policies for pods called the Pod Security Standards (PSS). The goal behind PSS is to decouple policy definitions from the means of policy enforcement. The following PSP controls also map to the PSS policy definitions.
Running of privileged containers
A “privileged” container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host.
This PSP control maps to the PSS Privileged Containers control which states that privileged containers must be disallowed. Here’s how can achieve this with OPA:
Example Policy:
Usage of host namespaces
Host namespaces, namely HostPID, HostIPC and HostNetwork, control whether the pod containers can share the host process ID namespace, host IPC namespace and node network namespace respectively. This PSP control maps to the PSS Host Namespaces control which states that pods should not be allowed to share host namespaces. The below OPA policy helps achieve this:
Example Policy:
Restricting escalation to root privileges
The AllowPrivilegeEscalation container option, when set to true, allows a child process of a container to gain more privileges than its parent. This PSP control maps to the PSS Privilege Escalation control which states that Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed. Here’s the OPA policy to enforce this control:
Example Policy:
These were just a few examples that show how PSP controls can easily be implemented using OPA, making OPA a great alternative when migrating from PSP. Another external admission controller that can ease the migration from PSP and can also perform all the checks that PSP provides would be OPA Gatekeeper — an admission controller that provides first-class integration between OPA and Kubernetes. In fact the Gatekeeper Policy Library already contains a number of policies needed in PSP that can be used with Gatekeeper!
So far we’ve seen how to implement the same controls as PSP using OPA and Rego. To enforce these policies in your Kubernetes clusters you will need to deploy OPA or OPA Gatekeeper into your clusters. If you want to do it yourself check out these resources:
Easily enforce PSP policies with Styra DAS
Can we make the PSP migration even more simple and also provide all the PSP controls out-of-the-box? Well look no further than Styra Declarative Authorization Service (DAS)! Styra DAS helps you operationalize OPA and get to production quickly and safely. Below, we’ll explore how you can get OPA up and running using Styra DAS in minutes.
Step 1: Installing OPA
With a couple of commands, Styra DAS seamlessly installs OPA in your Kubernetes cluster as both a validating and mutating admission controller. This allows you to not only validate all workloads against your custom policies but also to modify non-compliant workloads before deployment.
Step 2: Enforcing PSP policy
Styra DAS provides a built-in policy library of over 100 policies (including all 16 control aspects of a pod) derived from real-world use cases! These policies can be enforced with a point-and-click user interface that makes it easy to add the necessary security guardrails in order to mitigate security and compliance issues.
To accelerate PSP migration, Styra DAS released the Pod Security Policies pack. This pack implements all the PSP controls such as:
- Prevent containers from running in privileged mode
- Disallow privilege escalation
- Prohibit containers from sharing HostPID or HostIPC namespace
- Ensure containers can be created with approved seccomp profiles
- And many more…
The Pod Security Policies pack eliminates the need for users to research, author and implement each PSP policy manually and gives them the confidence to quickly enforce these checks in their cluster without having to worry about human errors or misconfigurations.
And that’s it! In two easy steps, you can get started with Styra DAS and enforce PSP policies in your Kubernetes cluster in less than 5 minutes!
Want to evaluate policies against your local Kubernetes manifests? Styra has you covered. Styra CLI provides the full power of Styra DAS from your terminal and allows you to check your local Kubernetes manifests against OPA policies.
Along with the easy installation steps and a number of built-in policies, Styra DAS also provides:
- OPA decision logging to help users understand why OPA made a particular decision
- Impact Analysis which allows users to see the impact of a new or updated policy on existing systems. For example, users can turn on PSP policies and see how they will affect their current clusters before actually enforcing them
- Managing and Monitoring OPAs deployed in the field
As Kubernetes starts the PSP deprecation process and eventual removal, this post highlights how OPA and Styra DAS provide the best solution to secure your Kubernetes cluster. Together, Styra DAS and OPA give you the ability to define security policies, not just for pods, but also for any other Kubernetes resources. We also explored how Styra DAS can help with a seamless migration from PSP and make rolling out PSP policies easier than ever!
Want to learn more about how OPA and Styra DAS can help keep your Kubernetes clusters safe? Schedule a demo with a Styra Engineer to learn about context-based admission control for Kubernetes.
FAQS
Are Pod Security Policies deprecated?
Yes. Kuberetes Pod Security Policies were deprecated in Kubernetes v1.21 and finally removed in v1.25
What is PSP in Kubernetes?
Kubernetes PodSecurityPolicy (PSP) was, in effect, an Admission Controller that allowed cluster managers to better control pod security by managing specific policies. This feature was fully removed in Kubernetes v1.25, and has been replaced with PodSecurity Admission, which is a simplified more user-friendly successor.