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:
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:
- 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:
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:
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.