Pod Security Standards define three security levels: Privileged (no restrictions), Baseline (minimum), and Restricted (strictest). They replace the previously used PodSecurityPolicy, which was removed in Kubernetes 1.25. PSS are built directly into Kubernetes as the Pod Security Admission controller — no external tools needed. Proper configuration significantly limits the impact of container compromise.
Levels¶
- Privileged: No restrictions — the container can do anything, including accessing host namespace and devices. Only for system components and infrastructure workloads (CNI plugins, CSI drivers).
- Baseline: Blocks known privilege escalation vectors — disallows hostNetwork, hostPID, privileged mode, and dangerous capabilities. Minimum standard for all workloads.
- Restricted: Hardened best practices for production — enforces non-root user, read-only root filesystem, drop ALL capabilities, seccomp profiles. The container runs with minimal privileges.
Enforcement¶
# Namespace label
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/audit: restricted
The three modes can be combined: enforce rejects non-compliant pods, warn shows warnings during kubectl deploy, and audit writes to the audit log. The recommended approach: start with warn+audit at the restricted level, fix non-compliant workloads, and only then enable enforce. This avoids unexpected outages during deployment.
Migration from PodSecurityPolicy¶
If migrating from PSP, audit mode shows which workloads would fail the restricted standard. Common issues: containers running as root, missing seccomp profile, unnecessary capabilities. Fix the Dockerfile (USER nonroot) and Kubernetes manifests (securityContext) before enabling enforcement.
Key Takeaway¶
Restricted for production, Baseline as the absolute minimum for any workload. Enforce at namespace level. Every new namespace should have PSS labels from the start.