Mastering Kubernetes Pod Security Best Practices

Kubernetes security isn’t just about protecting clusters from external attacks — it’s about enforcing secure behavior at every layer. Pod Security Policies (PSPs) are one of Kubernetes’ foundational tools for doing that. They define what’s allowed to run inside your pods and how workloads interact with the host, helping teams apply consistent container security best practices across environments. While PSPs have evolved into Pod Security Standards, the principles behind them remain central to modern kubernetes security programs.

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. This blog post is part of a series about container security.

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, helping align with microservices security models that isolate workloads by function and minimize cross-service risk.

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). Just as container vulnerability scanning ensures images meet baseline security requirements, PSPs ensure that workloads conform to your Kubernetes cluster’s security posture before they run.

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 — complementing cluster-wide Container Security Scanning efforts that enforce consistency across environments.

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.

Scan and validate before enforcing policies

Before applying or updating Pod Security Policies, scan your container images for known vulnerabilities using docker image scanning tools. This helps ensure the workloads entering your cluster meet both image-level and policy-level requirements. Continuous container scan integration into your CI/CD pipeline ensures that unsafe images are blocked before deployment.

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.

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 PSPs by default, it’s important to make sure yours does. For secure orchestration setups, align this with your Docker container security configuration and admission control processes.

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. Overprivileged containers are among the most common docker container vulnerabilities and can be mitigated by strict privilege policies and runtime monitoring.

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 kubernetes security best practice is to require containers to run with a read-only file system. This measure, paired with docker image security, helps enforce immutability and reduces the surface area for attacks. 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

Preventing privilege escalation isn’t just a cluster configuration choice — it’s a cornerstone of layered container security tools that also include runtime visibility and anomaly detection.

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. This aligns with Container security best practices for enforcing least privilege within pods and workloads.

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

Once policies are consolidated, ensure that they’re applied alongside your update docker images workflow, so new or rebuilt containers inherit the same hardened configurations.

Automate and Monitor Your Pod Security Posture

Kubernetes security doesn’t stop at configuration. Continuous monitoring is key to identifying drift and misconfigurations before they lead to compromise. Use Container security tools that integrate with your cluster to track policy compliance, runtime threats, and container vulnerability trends over time.

Many DevSecOps teams also combine these insights with CI/CD-integrated docker image scanning to ensure new workloads are automatically validated before entering production. When done right, this automation extends PSP protections into your entire SDLC.

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. Combined with container security best practices, PSPs lay the groundwork for a secure, compliant, and resilient cluster — the cornerstone of any mature kubernetes security strategy.