Pod Security Standards: Three Tiers and Where Each Fits

PSS replaces PSP with three tiers: privileged, baseline, restricted. The right tier per workload class.

Privileged

Pod Security Standards (PSS) are Kubernetes' replacement for the deprecated PodSecurityPolicy. They define three tiers: Privileged, Baseline, and Restricted. Each tier applies progressively stricter controls. Choosing the right tier for each namespace is the discipline that produces secure, sustainable Kubernetes operations.

What the Privileged tier provides:

• Full access.: Privileged is the most permissive tier. Pods can run as privileged containers, use host networking, mount host paths, and access raw devices. Almost no security controls apply at this tier.
• System-level workloads only.: The Privileged tier is intended for system-level workloads: CSI drivers that need direct device access, network plugins that need privileged operations, monitoring agents that need host-level visibility. Application workloads should not run at this tier.
• CSI drivers.: Storage CSI drivers often need privileged access to mount and manage storage. The Privileged tier accommodates them; alternatives would require pervasive workarounds.
• Network plugins.: CNI plugins (Calico, Cilium, similar) typically need privileged access to configure network namespaces and iptables rules. The Privileged tier is the right fit; the plugins genuinely need this access.
• Locked to specific namespaces.: Privileged is locked to system namespaces (kube-system) and explicitly approved namespaces. Application namespaces never use Privileged. The lockdown is the discipline that prevents the escape valve from becoming the default.

Privileged is the escape valve, not the default. Workloads need explicit justification to run at this tier.

Baseline

Baseline is the middle tier. It blocks the most egregious security patterns while accommodating common application requirements. For most application namespaces, Baseline is the right default unless the team has done the work to move to Restricted.

• Reasonable defaults.: Baseline blocks privileged containers, host network usage, host path volumes (with some exceptions), and similar high-risk patterns. The defaults are conservative without being prohibitive.
• Most application workloads fit.: Typical web applications, microservices, and batch jobs run cleanly under Baseline. The tier accommodates the patterns most teams use without requiring code changes.
• Allows common patterns.: Some access patterns that Restricted blocks are allowed under Baseline: certain host path patterns, volume types, capabilities. The accommodation reflects practical compatibility with common workloads.
• Blocks the egregious ones.: Privileged containers, host network, host process namespace, host IPC namespace, dangerous capabilities. The Baseline tier blocks the patterns that have produced the most security incidents historically.
• Reasonable migration target.: Teams moving from no security policy to PSS often start with Baseline. The migration is achievable; existing workloads typically fit; the security improvement is meaningful.

Baseline is the practical default for most application namespaces. The bar for adoption is low; the security value is real.

Restricted

Restricted is the strictest tier. It enforces zero-trust principles at the pod level: drop all capabilities, run as non-root, use seccomp profiles, restrict volume types significantly. New workloads should target this tier; existing workloads need refactoring to fit.

• Hardened.: Restricted enforces strict security defaults: drop all Linux capabilities, run as non-root user, use the runtime/default seccomp profile, restrict volume types to a small allowed set. The defaults are deliberately strict.
• Zero-trust workloads.: The tier aligns with zero-trust principles: assume the workload could be compromised; minimize what compromise can do. The tier reflects the assumption that any workload might be malicious.
• New workloads should target this.: When designing new workloads, target Restricted from the start. The cost of designing for Restricted upfront is small; retrofitting later is expensive.
• Blocks more than Baseline.: Restricted enforces requirements Baseline does not: non-root user, seccomp, capability dropping. Some workloads that work under Baseline do not work under Restricted; refactoring is required.
• Some apps need adjustment to fit.: Legacy applications often need adjustment: change image to use non-root user, configure capability dropping, use Restricted-compatible volumes. The adjustment is one-time; the long-term security value is permanent.

Pod Security Standard tier choice is one of the most consequential namespace-level decisions in Kubernetes operations. Nova AI Ops integrates with cluster admission and audit data, surfaces tier mismatches and migration candidates, and produces the per-namespace tier inventory that the platform team uses to drive harder defaults over time.