What are Kubernetes Pod Security Standards?
Learn the three Kubernetes Pod Security Standards levels, how enforcement labels work, and why they replaced PodSecurityPolicy.
Expected Interview Answer
Pod Security Standards are three predefined policy levels — Privileged, Baseline, and Restricted — built into Kubernetes that define what a Pod is allowed to do at the OS and kernel level, enforced today through the built-in Pod Security Admission controller labeling namespaces.
Privileged is unrestricted and meant only for trusted system components like CNI plugins or node agents; Baseline blocks the most obviously dangerous settings such as host namespaces, privileged containers, and most Linux capabilities while remaining broadly compatible with typical workloads; Restricted is the most locked-down, additionally requiring a non-root user, a read-only root filesystem where practical, dropping ALL capabilities, and disallowing privilege escalation. Enforcement is configured per namespace via labels like `pod-security.kubernetes.io/enforce: restricted`, and separate `warn` and `audit` labels let you see what would be blocked before actually enforcing it, which is the recommended rollout path. This replaced the older PodSecurityPolicy (PSP) API, which was deprecated in 1.21 and removed in 1.25 because its admission-controller-plus-RBAC-binding model was notoriously hard to reason about and easy to misconfigure. Pod Security Standards intentionally cover only Pod-level security context fields — they do not enforce network policy, image provenance, or resource quotas, which is why they are commonly paired with a policy engine like Kyverno or OPA Gatekeeper for anything beyond the three built-in levels.
- Built into core Kubernetes, no extra controller to install for basic enforcement
- Simple three-tier model that is easy to reason about compared to PSP
- warn/audit modes allow safe, staged rollout before hard enforcement
- Reduces kernel-level attack surface from compromised containers
AI Mentor Explanation
Pod Security Standards are like a ground’s three-tier equipment rulebook: groundstaff areas allow anything (privileged), the practice nets enforce basic safety gear like helmets against fast bowling (baseline), and the main match arena enforces the strictest kit — approved bats only, no metal spikes on certain surfaces, full protective gear (restricted). A stadium tags each area with which rulebook applies, and officials can run a trial “warning” period where violations are logged but players are not yet turned away. The old, ad-hoc “ask the ground curator” system before this rulebook existed was replaced because too many curators interpreted the rules differently.
Step-by-Step Explanation
Step 1
Choose a level
Pick Privileged, Baseline, or Restricted based on the workload’s trust level.
Step 2
Label the namespace
Set pod-security.kubernetes.io/enforce (and warn/audit) labels on the namespace.
Step 3
Roll out via warn/audit first
Use warn and audit modes to see violations logged without blocking Pods.
Step 4
Switch to enforce
Once workloads are compliant, set enforce to actually block non-compliant Pods.
What Interviewer Expects
- Knowledge of the three levels: Privileged, Baseline, Restricted
- Understanding of namespace-label-based enforcement via Pod Security Admission
- Awareness that PSP was deprecated/removed and why it was replaced
- Recognition that PSS covers only Pod-level security context, not network policy or images
Common Mistakes
- Confusing Pod Security Standards with PodSecurityPolicy (the deprecated API)
- Applying enforce: restricted without first checking with warn/audit
- Believing Pod Security Standards also enforce network segmentation
- Not knowing labels are set per namespace, not per Pod
Best Answer (HR Friendly)
“Pod Security Standards give us three built-in security tiers for Kubernetes namespaces — permissive, baseline, and restricted — so we can lock down what a container is allowed to do at the OS level, like running as root or accessing the host network. We usually roll a stricter tier out in “warn” mode first so we can see what would break before we actually start blocking anything.”
Code Example
apiVersion: v1
kind: Namespace
metadata:
name: payments
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: latest
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/audit: restrictedFollow-up Questions
- What specifically does the Restricted level require in a Pod’s securityContext?
- Why was PodSecurityPolicy removed in Kubernetes 1.25?
- How would you migrate a namespace from Baseline to Restricted safely?
- What is not covered by Pod Security Standards that a tool like Kyverno would add?
MCQ Practice
1. How many built-in Pod Security Standards levels are there?
There are exactly three levels: Privileged, Baseline, and Restricted.
2. How is Pod Security Standards enforcement configured?
Enforcement, warn, and audit modes are set as labels on the namespace, applying to all Pods created within it.
3. What replaced PodSecurityPolicy after its removal in Kubernetes 1.25?
The Pod Security Admission controller, enforcing the three Pod Security Standards levels, is the built-in replacement for PSP.
Flash Cards
Name the three Pod Security Standards levels? — Privileged, Baseline, and Restricted.
How is a level enforced? — Via pod-security.kubernetes.io/enforce label on the namespace.
What did Pod Security Standards replace? — PodSecurityPolicy (PSP), deprecated in 1.21 and removed in 1.25.
What is the recommended rollout strategy? — Use warn/audit modes first, then switch to enforce once compliant.