Kubernetes ships three built-in Pod Security Standards — Privileged, Baseline, and Restricted — that define what a pod is allowed to do on a cluster, from running as root to mounting the host filesystem. They replaced PodSecurityPolicy (PSP), which was deprecated in Kubernetes 1.21 (April 2021) and fully removed in 1.25 (August 2022), leaving a gap that the Pod Security admission controller now fills natively. Since 1.25, every cluster ships with this admission controller enabled by default, enforced through simple namespace labels rather than a separate policy object. For teams running multi-tenant clusters, regulated workloads, or just trying to pass a CIS Kubernetes Benchmark audit, PSS is the baseline control for stopping privilege escalation, host namespace sharing, and dangerous capability grants before a pod ever starts. This glossary post breaks down the three levels, how enforcement works, and where teams still get it wrong.
What are Kubernetes Pod Security Standards?
Kubernetes Pod Security Standards (PSS) are three predefined security profiles — Privileged, Baseline, and Restricted — that Kubernetes uses to evaluate whether a pod's security context and configuration are safe to admit. They were introduced as part of KEP-2579 and became a stable, built-in feature in Kubernetes 1.25 (GA, August 2022). Each profile is a fixed checklist covering things like hostNetwork, hostPID, hostIPC, privileged containers, allowed Linux capabilities, seccomp profiles, and whether containers can run as UID 0. Unlike PodSecurityPolicy, which required writing and binding custom policy objects via RBAC, PSS profiles are non-configurable — you pick one of the three levels per namespace and Kubernetes enforces it directly through the API server's admission chain, with no third-party controller or CRD required.
What are the three Pod Security Standard levels?
The three levels are Privileged, Baseline, and Restricted, ordered from least to most locked down. Privileged is wide open by design — it's meant for cluster-level infrastructure components like CNI plugins or node-monitoring daemonsets that genuinely need host access, and it disables nearly all checks. Baseline blocks the most well-known privilege escalations: no privileged containers, no host namespaces (hostNetwork, hostPID, hostIPC), no hostPath volumes unless explicitly listed as safe, and a restricted set of Linux capabilities (no SYS_ADMIN, NET_ADMIN, etc.). Restricted goes further, layering on Pod Security best practices: containers must run as non-root, must set allowPrivilegeEscalation: false, must drop ALL capabilities by default, and must use RuntimeDefault or a custom seccomp profile. Most production namespaces handling customer data should target Restricted; most vendor-supplied Helm charts default to something closer to Baseline out of the box.
How do Pod Security Standards replace PodSecurityPolicy?
Pod Security Standards replace PodSecurityPolicy by moving enforcement from a cluster-scoped API object into a built-in admission controller configured through namespace labels. PSP required creating a PodSecurityPolicy resource, then binding it to service accounts or groups via RBAC ClusterRole/ClusterRoleBinding objects — a setup notoriously easy to misconfigure, which is a big reason SIG-Auth deprecated it starting in Kubernetes 1.21. With PSS, enforcement is three labels on a namespace: pod-security.kubernetes.io/enforce, audit, and warn, each set to privileged, baseline, or restricted. For example, kubectl label ns payments pod-security.kubernetes.io/enforce=restricted immediately blocks any pod in that namespace violating the Restricted profile, while audit and warn labels let teams see violations in API server audit logs or kubectl warnings before flipping enforcement on. Clusters still running pre-1.25 versions or relying on PSP replacements should note PSP's removal in 1.25 means any cluster upgraded past that version without a migration plan loses enforcement entirely, not just the ability to create new policies.
How do you check if existing workloads violate Pod Security Standards?
You check for violations by applying a namespace label in warn or audit mode first, which reports violations without blocking anything. Setting pod-security.kubernetes.io/warn=restricted on a namespace causes kubectl apply and kubectl create to print inline warnings for every non-compliant pod spec, while audit=restricted writes the same findings into the API server's audit log with the pod-security.kubernetes.io/audit-violations annotation for later review. The Kubernetes project also ships a standalone pod-security-admission label syncer and CLI tooling (e.g., kubectl-validate and Pod Security's built-in --dry-run=server support) so teams can dry-run an entire namespace's manifests against Restricted before touching the enforce label. In practice, a 200-pod namespace migrating from Baseline to Restricted typically surfaces violations in a handful of common categories — root-user containers, missing seccompProfile, and containers requesting capabilities like NET_RAW — rather than dozens of distinct issues, because most Helm chart defaults cluster around the same handful of unsafe defaults.
What are the most common Restricted-profile violations in real clusters?
The most common Restricted-profile violations are running as root, allowing privilege escalation, and failing to drop Linux capabilities. Concretely: a container without runAsNonRoot: true fails immediately, since Restricted requires every container either set that field or otherwise guarantee a non-zero UID. Second, allowPrivilegeEscalation defaults to true in the Docker and containerd runtimes unless explicitly set to false, so almost any manifest copy-pasted from a tutorial fails Restricted on this alone. Third, Restricted requires containers to drop the full default capability set (capabilities.drop: ["ALL"]) and only add back what's needed — but most base images and popular charts (older Bitnami charts prior to their 2023 security-context overhaul, for instance) ship without a capabilities block at all, inheriting the container runtime's default set of roughly 14 capabilities. Fourth, Restricted mandates a seccompProfile.type of RuntimeDefault or Localhost; pods with no seccompProfile field set at all — still common in CI/CD-generated manifests — fail this check even if every other field is compliant.
Do Pod Security Standards satisfy compliance frameworks like CIS or SOC 2?
Pod Security Standards contribute to but do not fully satisfy frameworks like the CIS Kubernetes Benchmark or SOC 2 on their own. The CIS Kubernetes Benchmark (v1.8, published 2023) maps several of its Section 5 "Policies" controls directly onto PSS's Baseline and Restricted checks — non-root execution, capability restrictions, host namespace isolation — so enforcing Restricted across namespaces closes a meaningful chunk of those findings. But CIS and SOC 2 auditors also expect evidence of network policy enforcement, image provenance, RBAC least-privilege, and audit logging retention, none of which PSS addresses; PSS only governs the pod spec fields Kubernetes admits, not what's inside the container image or how traffic flows between pods. Teams preparing for a SOC 2 Type II audit typically pair Restricted-profile enforcement with a network policy engine (e.g., Cilium or Calico), an OPA/Kyverno policy layer for anything outside PSS's fixed checklist (like disallowed image registries), and image-scanning evidence — PSS is one control among several, not a complete compliance program.
How Safeguard Helps
Safeguard extends Pod Security Standards enforcement from "is this pod spec compliant" to "does this violation actually matter in production." Our reachability analysis correlates a namespace's Restricted-profile gaps — like a missing seccompProfile or an undropped capability — with whether the container actually exercises the code path that capability protects, so teams triaging hundreds of Baseline-to-Restricted findings can prioritize the handful that are truly exploitable rather than treating every warning as equal. Griffin AI, Safeguard's autonomous remediation agent, reads the pod spec and the base image's SBOM together and opens auto-fix PRs that add the correct securityContext fields — non-root UID, dropped capabilities, RuntimeDefault seccomp — without breaking the container's runtime behavior. Safeguard also generates and ingests SBOMs across your cluster's images so PSS violations, vulnerable dependencies, and capability requirements show up in one place instead of three separate tools. For teams migrating from PodSecurityPolicy or standing up Restricted enforcement for the first time, this turns a manual, chart-by-chart audit into a prioritized, PR-driven rollout.