Enforce Pod Security Admission

The fix

# Enforce the restricted standard on a namespace with three labels
kubectl label namespace orders \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

PodSecurityPolicy is gone — don’t look for it

If a hardening guide tells you to write a PodSecurityPolicy, stop reading it. PSP was deprecated in 1.21 and removed entirely in 1.25. The API doesn’t exist. A cluster on any current version has no PSP, and manifests referencing it are inert.

Its replacement, Pod Security Admission (PSA), is built into the API server and works completely differently — and much more simply. There’s no policy object, no RBAC binding, no controller to install. You apply one of three built-in Pod Security Standards to a namespace with labels, and the API server enforces it on every pod created there.

This matters because the two are not similar. Time spent trying to make PSP work, or copying a PSP-based guide, is time spent on an API that Kubernetes removed. PSA is the answer, and it’s less work.

The three standards

Standard	What it allows
privileged	Everything — no restrictions. The unsafe default.
baseline	Blocks known privilege escalations: no privileged, no host namespaces, no hostPath, limited capabilities.
restricted	Baseline plus hardening: must run as non-root, drop all capabilities, seccomp RuntimeDefault, read-only where possible.

restricted is the target for application namespaces — it enforces most of the workload security context automatically, so a pod that tries to run privileged or as root is rejected at admission. baseline is the pragmatic floor when restricted breaks too much to adopt at once.

The unlabelled default is effectively privileged — no enforcement — which is why a fresh namespace lets a pod request anything.

The three modes

Each standard can be applied in three modes, and using them together is how you adopt safely:

• enforce — reject pods that violate the standard. The teeth.
• warn — allow, but return a warning to the user who created it.
• audit — allow, but record a violation in the audit log.

Set warn and audit to restricted before you set enforce, so you see what would be rejected without breaking anything. That’s the safe rollout, and it’s the whole reason the three modes exist.

It’s per-namespace, and kube-system is exempt

PSA is applied per namespace, so hardening the cluster means labelling every application namespace — a new namespace with no label has no enforcement. kube-system and other control-plane namespaces legitimately run privileged pods and should not be set to restricted; scope your enforcement to workload namespaces.

For cluster-wide defaults, the API server’s AdmissionConfiguration can set a baseline that applies everywhere unless a namespace overrides it — better than relying on remembering to label each one.

Verify it worked

See which namespaces have PSA labels — and which don’t:

kubectl get namespaces -o custom-columns=\
'NAME:.metadata.name,ENFORCE:.metadata.labels.pod-security\.kubernetes\.io/enforce'

Application namespaces showing <none> have no enforcement — the finding.

Prove enforcement works — try to create a privileged pod in a restricted namespace:

kubectl -n orders run test --image=busybox --privileged --restart=Never -- sleep 1

Expect rejection:

Error ... violates PodSecurity "restricted:latest": privileged (...)

If it creates, the namespace isn’t enforcing. Clean up: kubectl -n orders delete pod test.

See what would be rejected before you enforce — check for existing violators:

kubectl label --dry-run=server --overwrite namespace orders \
  pod-security.kubernetes.io/enforce=restricted

That server-dry-run reports every currently-running pod that would violate the standard, without applying it — the single most useful command for planning this.

Before you apply this

Setting enforce=restricted on a namespace with non-compliant workloads blocks their next deployment — the running pods keep running, but any recreate, restart, scale-up or rolling update is rejected, which surfaces as a deployment that won’t progress. That’s a delayed outage: fine now, broken at the next deploy.

The safe adoption path is the whole point of the modes:

1. kubectl label ns X pod-security.kubernetes.io/warn=restricted pod-security.kubernetes.io/audit=restricted — no enforcement, just visibility.
2. Watch warnings and the audit log for violations. Fix the workloads — add the security context that restricted requires.
3. Use the --dry-run=server check above to confirm nothing violates.
4. Only then add enforce=restricted.

The common violations to fix first: containers running as root (need runAsNonRoot: true and a runAsUser), missing allowPrivilegeEscalation: false, capabilities not dropped, and no seccomp profile. Legacy images that assume root are the usual blocker — restricted requires non-root, and some images simply won’t run that way without a rebuild.

Don’t apply restricted to kube-system or your CNI/CSI namespaces — those run privileged by necessity, and enforcing restricted there breaks the cluster’s own plumbing. Scope enforcement to application namespaces.

Related

• Restrict privileged containers — the settings restricted enforces.
• Audit logging — where PSA audit mode records violations.