PodSecurityStandards vs. PodSecurityPolicies

PodSecurityStandards (PSSs) have replaced PodSecurityPolicies (PSPs) as Kubernetes' builtin security control.

That said, they're quite different. Here are the top 6 things to know about Pod Security Standards.

1. Pod Security Standards are opinionated

Pod Security Policies (now deprecated) were a tool for creating policies. But the content of those policies was up to you.

With Pod Security Standards, there is no more creating policies! You get three predefined security levels out of the box, and there's no customizing them.

2. Pod Security Standards apply to namespaces

Pod Security Standards are applied to namespaces. When applied, they impose requirements on all Pods in the namespace.

3. To set a Pod Security Standard, you label the namespace

Interesting design decision here. Namespaces don't have a new YAML field specifying their Security Standard. Instead, you just add a special label to the namespace:

kubectl label namespace kube-system pod-security.kubernetes.io/enforce=baseline

4. Pod Security Standards can be enforced, warning-only, or audit-only

Security Standards are checked at runtime via admission control.

There are three possible modes:

kubectl label namespace kube-system pod-security.kubernetes.io/enforce=baseline
kubectl label namespace kube-system pod-security.kubernetes.io/warn=baseline
kubectl label namespace kube-system pod-security.kubernetes.io/audit=baseline

• Enforcement mode is self-explanatory.
• Warning mode shows the user a warning when they run `kubectl apply` but allows the Pod to run.
• Audit mode is the same as warning, but the message goes to the Kubernetes audit log instead of kubectl output.

5. You can check namespaces in advance with --dry-run

Before applying a PSS to a namespace, you can do a --dry-run and see which pods violate the standard:

kubectl label --dry-run=server --overwrite ns --all pod-security.kubernetes.io/enforce=baseline

This will output a warning for pods that wouldn't be able to run under the proposed standard.

6. Pod Security Standards cause owned Pods to fail silently

First off, terminology. By owned Pods, we mean Pods inside a ReplicaSet, DaemonSet, etc. These Pods aren't created directly by users. Instead, users create the owner resource which spawns pods.

To understand the problem, imagine you have a namespace with a Security Standard in-place. First you try to deploy a non-owned (regular) Pod to that namespace. If the Pod violates the Security Standard, kubectl apply fails.

But what happens if you kubectl apply a Deployment that creates the problematic Pod? In this case, creating the Deployment succeeds! There's no error, because the Deployment itself passes Admission Control. But the Pods from that Deployment will never run because Admission Control blocks them. So kubectl apply succeeds, but the Deployment won't actually run.

This is clearly a problem.

One solution is to run the psa-checker tool on the Deployment in advance. 6 minute, 45 second video on psa-checker here.

Videos about Pod Security Standards

Are you a visual learner?

Here are two YouTube videos we recorded, each 7 minutes or under:

• Checking Pod Security Standards on Kubernetes with psa-checker
• PodSecurityStandards vs PodSecurityPolicies

KubeCon EU 2023

Are you attending KubeCon next month?

Come to the Robusta.dev booth. Tell us if you liked this post.‍

We're redefining Kubernetes observability and have some surprises coming soon.