What is the difference between Pod Security Policy and Pod Security Standards?

Pod Security Policy is an older Kubernetes mechanism for blocking misconfigured pods with a fixed set of controls. Pod Security Standards are the newer official baseline and restricted policy set for pod security, designed to be enforced by any tool that can validate OPA or Rego checks. PSS is the preferred policy model for current Kubernetes governance.

How Pod Security Policy and Pod Security Standards differ in practice

Pod Security Policy was a cluster-level admission control mechanism that let administrators define detailed constraints for pods. It was powerful but operationally heavy, because teams had to author and maintain policy objects themselves. pod security standards replace that model with a smaller, opinionated set of built-in pod security levels that Kubernetes can enforce consistently across namespaces and tools.

The key difference is scope and maintenance burden. PSP exposed many knobs, which made it flexible but also difficult to govern at scale. PSS deliberately narrows the policy surface to make baseline enforcement more predictable, with clearer expectations for what is allowed in baseline and restricted workloads.

That design shift matters for governance. PSP could express organisation-specific policy, but it also made portability and consistency harder because enforcement depended on the chosen admission path. PSS is intended as the common policy language for pod hardening, so the same security expectation can be applied by Kubernetes-native controls or external policy engines that understand the standard.

Why Kubernetes moved from a bespoke policy object to standardised pod controls

PSP was removed because it placed too much policy complexity into a single mechanism that was hard for many operators to use correctly. In practice, teams often needed one policy for privileged system workloads, another for application namespaces, and exceptions for legacy workloads, which created drift and review fatigue. PSS reduces that complexity by giving operators a shared baseline vocabulary rather than a custom rule set for every case.

The practical benefit is easier review and clearer intent. Instead of trying to determine whether a PSP author remembered every dangerous combination of host access, privilege escalation, capabilities, and volume behaviour, reviewers can compare a pod against the standard level the namespace is meant to enforce. That lowers ambiguity during platform governance and makes it easier to explain policy decisions to application teams.

For clusters that still need more granular control, current guidance is to layer additional admission or policy tooling on top of PSS rather than treating PSS as a complete replacement for every bespoke rule. PSS is the baseline contract; it is not the only control you may need if your environment has special workload classes, regulated namespaces, or tighter blast-radius requirements.

What practitioners should carry forward from the PSP to PSS transition

PSS is best understood as a default guardrail, not a direct one-for-one migration target from PSP. The old policy may have captured organisation-specific exceptions that should now be re-evaluated, because simply translating PSP settings into a new tool can preserve old complexity instead of simplifying governance. The new model works best when teams decide which namespaces should be privileged, which should be baseline, and which should be restricted by default.

That means the important implementation work is not only technical enforcement, but also policy rationalisation. Teams should review where they previously depended on PSP to allow host namespaces, added capabilities, privileged containers, or unsafe volume patterns, then decide whether those exceptions are still justified. In many cases, the right answer is to redesign the workload, not to recreate the old exception permanently.

NIST SP 800-53 Rev 5 Security and Privacy Controls is useful when you need to map pod hardening to broader access control and configuration management expectations. For environment-level hardening, CIS Benchmarks help align the surrounding platform with the assumptions behind restricted pod policy, and NIST Cybersecurity Framework 2.0 gives a governance lens for making the baseline enforceable and auditable.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-3 — Access Enforcement	Pod security standards enforce what pods may do at runtime.
	CM-6 — Configuration Settings	PSS defines standard pod hardening settings and reduces config drift.
Recommendation — Enforce pod restrictions consistently through access enforcement controls. Baseline and review pod security settings as managed configuration.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Pod hardening is a secure configuration problem at cluster and workload level.
	CIS-5 — Account Management	Privileged pod exceptions often depend on tightly controlled access paths.
Recommendation — Apply secure configuration baselines to Kubernetes and workload settings. Limit elevated access paths to workloads and administrators.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication and Access Control	Pod security policy decisions restrict what running workloads may access or do.
Recommendation — Enforce least-privilege access and authorization for pod execution contexts.

Practitioner Guidance

What to verify: Confirm which namespaces genuinely need elevated pod permissions before you migrate policy. If every workload is treated as an exception, PSS will not improve your posture and you will only move the same risk into a newer control model.

Decision rule: If a workload needs host access, privileged execution, or broad capability sets, treat that as an architectural exception that needs explicit approval and review. If it only needs to pass today because of a legacy deployment pattern, prioritise workload redesign over policy relaxation.

Practitioner takeaway: The real upgrade from PSP to PSS is not just a new control mechanism, it is a shift from bespoke per-cluster policy crafting to a simpler, more governable pod security baseline that should reduce exception sprawl.