Pod Security Admission enforces a security standard per namespace through labels. It replaced the removed PodSecurityPolicy, and it works by rejecting or warning about pods that violate the chosen level, so a namespace cannot accumulate privileged workloads by accident.
Before you start
You should be comfortable with security contexts and namespaces. This article covers the admission levels and migration.
Step-by-step walkthrough
Step 1: Label namespaces with a level
The baseline level blocks known privilege escalations such as host networking, and restricted adds requirements like running as non-root and dropping capabilities. Label a namespace with the mode (enforce, warn, audit) and the level, so the policy is scoped and visible.
Step 2: Make pods satisfy the level
A restricted namespace requires pods to set a securityContext with runAsNonRoot, a read-only root filesystem where possible, dropped capabilities and a seccomp profile. Missing settings cause rejection, so the pod spec must declare them explicitly.
Step 3: Roll out with warn and audit first
Apply warn and audit modes before enforce, so you can see which workloads would fail without breaking them. Fix those pods, then switch to enforce. This staged approach avoids a surprise outage when the policy tightens.
Worked scenario
The namespace enforces the restricted standard.
apiVersion: v1
kind: Namespace
metadata:
name: payments
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/warn: restrictedWalk through the example
Pods in payments must satisfy the restricted level or be rejected. The warn label surfaces violations as warnings, which helps during rollout. A pod that omits runAsNonRoot or requests privileges is blocked, which keeps the namespace hardened without a separate policy object.
Common mistake
Switching straight to enforce on an existing namespace, so running deployments that do not meet the level fail to update. Another is a pod that claims to run as non-root but uses an image whose user is root, which fails at runtime.
Verify the behavior
Deploy a privileged pod into the restricted namespace and confirm it is rejected. Add the required securityContext and confirm it is accepted. Use warn mode and check events for the violations before enforcing.
Interview exercise
Why apply warn and audit before enforce?
Answer and reasoning
They report which existing workloads would violate the level without blocking them, so you can find and fix the pods first. Enforcing immediately would cause those workloads to fail their next update, potentially taking down services. Staging the rollout turns a cliff into a controlled migration.
Continue learning
Compare runtime hardening in Security contexts and least privilege in RBAC least privilege. Read the Kubernetes pod security admission documentation and try the Kubernetes interview questions.