Pod Security Policies

What Pod Security Policies control in Kubernetes

Pod Security Policies were an admission-time control in Kubernetes that evaluated a pod before it started. They constrained what the workload could request from the cluster, including privileged execution, host namespace access, Linux capabilities, and volume types.

That made them a policy enforcement point rather than a runtime detector. The practical value was in stopping unsafe pod specs from ever being admitted, which reduced the chance that a workload could inherit cluster-level privileges it did not need.

Why Pod Security Policies matter for cluster hardening

Pod Security Policies matter because a pod is one of the easiest places for privilege creep to enter a Kubernetes environment. If admission rules are weak or absent, teams may unintentionally allow containers to run as root, mount sensitive host paths, or use capabilities that expand their reach beyond the container boundary.

For a broader hardening view, the Kubernetes Security Guide places pod admission, control-plane hardening, and workload isolation into the same defensive model. Pod-level restrictions only work well when they are part of that larger cluster security posture.

How Pod Security Policies changed workload permissions

At a technical level, Pod Security Policies acted on the pod specification and the service account or user context that submitted it. They could allow or deny settings for privilege escalation, host networking, host PID or IPC access, file system mounts, and other settings that materially affect container isolation.

That makes them closely tied to authorization in the Kubernetes control plane. The policy does not decide business access, but it does decide whether a workload is allowed to ask for a more dangerous execution environment than the cluster owner intended.

In environments where pods are coupled to service accounts, tokens, or other workload credentials, the Kubernetes NHI Security Guide is a useful companion because it connects admission control to the identity and privilege model behind workloads.

What changed after Pod Security Policies were removed

Pod Security Policies were removed from Kubernetes, so organisations can no longer rely on them as a native control in current clusters. The replacement pattern is to use newer admission and policy mechanisms, along with pod security standards and complementary controls, to preserve the same guardrails.

That transition matters operationally because a policy that exists only in documentation but not in the cluster leaves a gap between intended hardening and actual enforcement. Teams should verify what is enforced at admission today, not what was enforced in an older cluster design.

Modern Kubernetes hardening usually combines admission policy, namespace boundaries, runtime monitoring, and explicit workload permissions. The core lesson from Pod Security Policies is still relevant: prevent unsafe workload configurations at the boundary where the cluster can stop them cleanly.

Risk and Threat Considerations

Weak or missing pod admission controls can turn an otherwise ordinary workload deployment into a privilege-escalation path. If a pod can request privileged settings, mount sensitive host resources, or run with excessive capabilities, a compromised application can become a foothold for cluster-wide impact.

Failure mechanism: An attacker or misconfigured workload exploits overly permissive pod settings to break containment, access host resources, or gain a stronger execution context than intended.

Impact: The result can include container escape conditions, access to sensitive node data, lateral movement within the cluster, or accelerated compromise of other workloads.

Practitioner Guidance

Why practitioners should care: Pod admission policy is one of the few places where Kubernetes can block unsafe workload intent before it reaches the node. If that layer is missing or too permissive, downstream monitoring has to detect problems after exposure has already occurred.

What to watch for: Look for workloads that request privileged mode, broad Linux capabilities, host namespace access, or unusual volume mounts. Those settings often indicate either a real platform requirement or a policy gap that should be justified explicitly.

Practitioner takeaway: Treat pod-level policy as a baseline control, then confirm that the cluster’s current admission stack, namespace strategy, and workload identity model still enforce the same protections after Pod Security Policies are no longer available.

Related resources from NHI Mgmt Group

• Why do passwords remain a security problem even with strong policies?
• How do security teams know if MCP access policies are too coarse?
• How should security teams implement contextual access policies in zero trust environments?
• How should security teams test RBAC policies before production rollout?