Pod Security Standards: enforce restricted without breakage

Roll out the restricted profile namespace by namespace, find violators with audit mode first, and carve exceptions that expire.

PodSecurityPolicy is gone. Its replacement, Pod Security Admission, is built into the API server and enforces the three Pod Security Standards — privileged, baseline, and restricted — with a single label per namespace. The trick is not turning it on; it is turning it on without breaking every workload that was quietly running as root. PSA is blunt but predictable — and that predictability is what makes a phased rollout possible.

This walkthrough labels a namespace in audit mode first, harvests violators from the audit log, fixes securityContext on each workload, then promotes to enforce. For RBAC and admission beyond pod-level posture, continue with Kubernetes administration.

Three profiles, one decision

baseline blocks the obviously dangerous — host namespaces, privileged containers, hostPath volumes. restricted goes further: non-root, no privilege escalation, a seccomp profile, and dropped capabilities. Most teams should target restricted for application namespaces and reserve baseline for the few workloads that genuinely need more — ingress controllers, CNI agents, storage drivers.

Start in audit mode

Never jump straight to enforce. Label the namespace with audit and warn first — the API server records violations to the audit log and returns a warning to kubectl, but still admits the pod. You get a complete list of what would break with zero downtime. Work through that list workload by workload before anyone gets paged by a production deploy failure.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    # observe only — nothing is blocked yet
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Deploy as usual for a sprint, then harvest the violations straight from the audit log. Each line names the namespace, the resource, and the specific field that failed — that is your fix list. Fix Deployments and StatefulSets in place; for Helm charts, patch the chart values or upstream template so the next upgrade does not revert your securityContext fixes.

Common fixes: set runAsNonRoot: true and a numeric runAsUser, add allowPrivilegeEscalation: false, drop all capabilities, and set seccompProfile: { type: RuntimeDefault } at pod level. Test in a staging namespace with enforce enabled before you flip production.

# pull restricted violations out of the audit log
grep 'pod-security.kubernetes.io/audit-violations' audit.log \
  | jq -r '.objectRef.namespace + "/" + .objectRef.name' \
  | sort -u

Promote to enforce

Once the warnings are quiet, flip enforce on. Keep warn and audit pinned to latest so you catch regressions when a new Kubernetes release tightens the standard. Pin enforce-version deliberately in production if you need a controlled upgrade window — latest moves when the cluster upgrades.

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

Where this goes next

PSA enforces pod-level posture but cannot express org policy like 'images must come from our registry' or 'every pod needs a cost-center label'. That is where Kyverno or OPA Gatekeeper pick up. Pair PSA for the baseline with a policy engine for the rules that are specific to you. The Kubernetes administration course covers RBAC, admission control, and cluster hardening in depth.

Related posts