Kubernetes Pod Security Policy (PSP) was a cluster admission control feature that constrained how pods could run, including privilege, host access and volume use. When enabled, it helped block unsafe workload configurations; when absent, administrators had to enforce equivalent controls through other admission or policy mechanisms to prevent privilege escalation and hostile pod behaviour.
What Kubernetes Pod Security Policy changed
Kubernetes Pod Security Policy (PSP) was an admission-time control that evaluated pod specifications before they were admitted to a cluster. Its purpose was to stop pods from requesting dangerous capabilities or mounting paths that would weaken cluster isolation.
PSP mattered because pod-level permissions are not just an application concern, they are a cluster trust boundary. If a workload can run as privileged, use the host network, or mount sensitive volumes, it can turn a simple deployment mistake into node compromise, credential exposure, or lateral movement inside the cluster.
What PSP actually restricted
PSP could constrain security-sensitive pod settings such as privilege escalation, Linux capabilities, host namespaces, hostPath volumes, running as root, and certain volume types. In practice, it was a policy gate that forced workloads to stay within a narrower, safer runtime envelope.
That made PSP especially relevant in multi-tenant clusters and in environments where developers could create or update workloads directly. It reduced the chance that a pod would inherit broad node-level power or interact with the host in ways that break container isolation.
Why PSP was difficult to operate well
PSP was powerful, but it was also rigid and often hard to scale across teams. Because it relied on admission-time enforcement, the policy model had to be designed carefully, matched to namespaces and service accounts, and kept aligned with how workloads were actually deployed.
When policy design was too loose, unsafe pods could still enter the cluster. When it was too strict, legitimate workloads failed to schedule and teams looked for workarounds that diluted the control. That tension is why many organisations moved toward newer policy mechanisms that are easier to reason about and maintain.
What PSP means now
PSP is best understood as a historical Kubernetes hardening mechanism rather than the current default approach. Modern clusters generally use newer admission and policy models to enforce pod security expectations, but the underlying goal is the same: prevent workloads from requesting privileges that should never be granted by default.
For readers comparing controls, the key lesson is that pod security is not optional. If one admission mechanism is removed or deprecated, an equivalent guardrail still has to exist somewhere else in the cluster security stack, especially for privileged workloads, host access, and volume controls.
Risk and Threat Considerations
Weak or missing pod security enforcement can turn a low-trust container into a path toward node compromise, secret theft, or cluster escape. The main danger is not the pod itself, but the extra access it may gain to the host, other workloads, or mounted credentials when unsafe settings are allowed.
Failure mechanism: An attacker or careless deployment can exploit privileged pod settings, host namespace access, or dangerous volume mounts to break isolation, read sensitive files, or escalate from container control to broader cluster control.
Impact: The result can be credential exposure, lateral movement, data access across namespaces, and persistent footholds inside the Kubernetes environment.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | PSP constrains pod privileges and supports least-privilege enforcement for workloads. |
| CM-7 — Least Functionality | PSP limits risky pod features and reduces the functions a workload can invoke inside the cluster. | |
| SI-4 — System Monitoring | Unsafe pod settings often lead to exploit paths that should be monitored for abuse or escape attempts. | |
| Recommendation — Enforce least privilege for pods and service identities that can request elevated runtime access. Allow only the pod capabilities and runtime settings that a workload actually needs. Monitor cluster activity for privileged workload creation and host access attempts. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | PSP is a secure-configuration control for Kubernetes workload admission and runtime settings. |
| Recommendation — Standardize secure Kubernetes pod settings and remove unsafe deployment defaults. | ||
Practitioner Guidance
Governance implication: Treat pod security as a policy design and enforcement problem, not a one-time cluster setting. If PSP is absent in your environment, ensure another admission-layer control is actually enforcing the same baseline expectations for privilege, host access, and volume use.
What to watch for: Any workload that requests privileged execution, hostPath access, host networking, or excessive Linux capabilities deserves review because those settings often mark the boundary between ordinary application behaviour and cluster-level exposure.
Related resources from NHI Mgmt Group
- Guide: Kubernetes Security Guide
- What is the difference between Kubernetes Pod Security Admission and admission controllers that validate policy and image signatures?
- How should security teams replace Pod Security Policy before it disappears from Kubernetes?
- Why does relying on Pod Security Policy create risk for Kubernetes governance?
- How should security teams implement policy as code across Kubernetes and Terraform?