Pod Security Standards
Pod Security Standards (PSS) are the successor to PodSecurityPolicy (deprecated in 1.21, removed in 1.25). They define three tiers. Privileged is unrestricted. Baseline prevents known privilege escalations. Restricted is current hardening best practice. They are enforced by the built-in PodSecurity admission controller. Opting in is a per-namespace label. No external controller required. For most clusters, PSS Baseline is one of the highest-impact security controls available to enable today.
The three tiers
- Privileged. Unrestricted. Intended for infrastructure pods (storage drivers, network agents).
- Baseline. Prevents known privilege escalations. No privileged containers, no hostPath, no hostNetwork, no hostPID, drop
CAP_SYS_ADMIN. Most workloads can run Baseline without modification. - Restricted. Hardened best practice. Non-root user, read-only root filesystem, drop ALL capabilities, seccomp RuntimeDefault. Often requires workload changes.
Enabling PSS admission
Add labels to each namespace:
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restrictedenforce blocks non-compliant pods. audit logs violations. warn shows kubectl warnings without blocking. The pattern above enforces Baseline while auditing for Restricted, which is a staged migration path.
PSS and PodSecurityPolicy
PodSecurityPolicy (PSP) was the original. Deprecated in 1.21, removed in 1.25. The PSS admission controller is built into the API server (no separate deployment) and operates via namespace labels instead of RBAC-bound policy objects.
For clusters still running PSP, migrating is straightforward: map existing PSPs to Baseline or Restricted labels. Tooling exists to automate much of the translation.
PSS limitations
PSS is coarse-grained. Three tiers is the whole catalog. Finer control (for example "Baseline plus block one extra capability") requires an external policy engine (OPA Gatekeeper, Kyverno, or a bundled admission controller such as Juliet's). The common pattern is PSS as the floor plus an external admission layer for custom rules.
Frequently asked about pod security standards
Should I enforce Baseline or Restricted?
Baseline broadly, Restricted where workloads can take it. Dev and CI namespaces typically run fine on Baseline. Restricted requires non-root images and read-only filesystems, which usually needs application changes.
What happens if I apply the label to a namespace with non-compliant pods running?
Existing pods keep running. Only new pod creates or updates are checked. Apply with warn first to see what would break before switching to enforce.
Can I exempt specific pods?
Yes, via the exemptions section of the admission configuration. Typical use case: whitelist infrastructure namespaces that legitimately need privileged containers.
Does PSS work with Windows containers?
Partially. Windows pod restrictions are evolving. Linux PSS is comprehensive. Windows PSS covers the subset of controls meaningful on Windows (no hostNetwork, no hostProcess without opt-in, and similar).
Does Juliet automate PSS adoption?
Yes. The Starter tier audits every namespace against Baseline and Restricted. Team and Pro add admission enforcement, with a staged migration path (warn to audit to enforce).
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.