Kubernetes Pod Security Policy Best Practices

In Kubernetes, pod security policies are a powerful tool for mitigating security risks and enforcing secure configurations within your Kubernetes environment. However, using Kubernetes pod security policies to maximum effect takes some effort. It’s unlikely that your default pod security policies (if in fact you have them set by default at all) are a good match for your needs.

With that challenge in mind, this article explains how to get the most out of Kubernetes pod security policies. We’ll begin by briefly explaining how the policies work and what the goal behind them is. We’ll then walk through best practices for making sure that Kubernetes pod security policies are optimized for your environment.

What are Kubernetes pod security policies?

Put simply, pod security policies are configurations that define which security-related conditions a Kubernetes pod has to meet in order to be accepted into a cluster. They regulate how pods can interact with resources such as networks and storage. They can also be used to configure role-based access control.

Another way to think about Kubernetes pod security policies is to describe them as a way to run automatic conformance tests on your Kubernetes cluster. In the security world, conformance testing is a strategy for ensuring that an environment or application meets predefined security standards before it is allowed to run. Kubernetes pod security policies do the same thing by preventing pods from running unless they meet the security requirements defined in the policy. (To be clear, you don’t have to trigger a conformance test to enforce Kubernetes pod security policies. As long as the policies are enabled and configured, Kubernetes enforces them automatically.)

Kubernetes pod security policies are a cluster-level resource

A point of clarification: Don’t let the term pod security policy confuse you. Although the name might make it sound like pod security policies define security settings for a specific pod, the opposite is actually true.

Kubernetes pod security policies are a cluster-level resource, meaning that they define security policies that apply to your entire cluster, not individual pods.

Defining and activating pod security policies

Pod security policies are specified in YAML files. If you’re reading this article and know what Kubernetes is, you probably also know what a YAML file is, so we won’t go into detail about that here. For details on the parameters that you can define in a pod security policy and some sample policy files, see the Kubernetes documentation.

Once you’ve written a pod security policy, you have to activate it using kubectl. Here’s an example:

kubectl create -f your-new-policy.yaml

Replace your-new-policy.yaml with the name of the policy file you created, of course.

Getting the most out of Kubernetes pod security policies

How can you get the most out of Kubernetes pod security policies? Your mileage will of course vary depending on your specific configuration and needs, but consider the following best practices for working with pod security policies.

Enable them!

First and foremost, make sure Kubernetes pod security policies are enabled. This may seem too obvious to list as a best practice, but because some Kubernetes distributions do not enable pod security policies by default, it’s important to make sure yours does.

Some Kubernetes distributions don’t support pod security policies at all. If that’s the case for you, you may wish to consider switching to a different distribution. In other cases, pod security policies are supported, but aren’t turned on by default when Kubernetes starts. If that applies to you, check your vendor’s documentation to determine how to enable pod security policies when Kubernetes starts. Typically, you can do this using a command-line flag.

Disable privileged containers

In a Kubernetes pod, containers can optionally run in “privileged” mode, which means that the processes inside the container have almost unrestricted access to resources on the host system. While there are certain use cases where this level of access is necessary, in general, it’s a security risk to let your containers do this.

You can easily prevent privileged containers from running by including the following in your Kubernetes pod security policy:

apiVersion: policy/v1beta1

kind: PodSecurityPolicy

metadata:

name: prevent-privileged-containers

spec:

privileged: false

Read-only file system

Another security best practice for Kubernetes is to require containers to run with a read-only file system. This is useful because it helps to enforce an immutable infrastructure strategy, since a container whose file system can’t be changed will have to be replaced in order to make changes. This mitigates some of the risks of malicious processes storing or manipulating data inside a container.

You can enforce a read-only file system policy with this Kubernetes pod security configuration:

apiVersion: policy/v1beta1

kind: PodSecurityPolicy

metadata:

name: read-only-fs

spec:

readOnlyRootFilesystem: true

To be sure, read-only file systems are not practical in all situations, but consider using them if you don’t have a good reason for allowing write access to your container’s internal data.

Prevent privilege escalation

To most admins, privilege escalation is a bad word. There’s rarely a case when you want to allow an application or process to gain more permissions than it has when it first starts.

You might therefore think that Kubernetes prevents privilege escalation by default, but you’d be wrong. In order to disallow privilege escalation on your cluster, you have to use a Kubernetes pod security policy like this:

apiVersion: policy/v1beta1

kind: PodSecurityPolicy

metadata:

name: no-privilege-escalation

spec:

allowPrivilegeEscalation: false

Prevent containers from running as root

Running things as a root user is another practice that should send shivers down most admins’ spines. Typically, there is no good reason to run things as root. It’s almost as bad as typing chmod -R 777 and pressing Enter.

Fortunately, Kubernetes pod security policies provide an easy way to prevent containers from running as root:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: no-privilege-escalation
spec:
MustRunAsNonRoot: true

Group your policies together

The Kubernetes pod security policies we’ve looked at above are written as individual files. You can configure your cluster that way if you want, but in production deployments, it makes more sense to combine all settings into a single file. That way, you only have one file to write and activate.

A file that specifies multiple security directives would look like this:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: example
spec:
privileged: false
spec:
readOnlyRootFilesystem: true
spec:
allowPrivilegeEscalation: false
spec:
MustRunAsNonRoot: true

Conclusion

As we’ve seen, Kubernetes pod security policies provide a handy way to enforce strong security settings across a cluster in an automatic fashion. While this topic may not rank high on your list of exciting things to talk about with colleagues, you shouldn’t overlook the importance of pod security policies as a way to keep Kubernetes and the containers running in it secure.

Secure containerized applications

See Mend Container