Skip to main content
Pod Security Standards (PSS) are Kubernetes’ built‑in mechanism for restricting what Pods may do at runtime. PSS enforces a baseline safety net directly in the API server—no installation required—making it a lightweight, reliable first line of defense. It replaces the deprecated PodSecurityPolicy removed in Kubernetes 1.25. In this article you’ll learn the three PSS levels, how enforcement modes are applied and combined, and how to enable PSS using only namespace labels.
The image lists learning objectives related to Pod Security, including understanding security levels, applying enforcement modes, configuring security with namespace labels, and implementing security settings for compliance.

​
The three security levels

PSS defines three named profiles that express increasing restrictions. Use them to scope what pod configurations are allowed in a namespace.
  • Privileged — no restrictions. Pods may use host network, hostPID, privileged containers, run as root, etc. Reserve this for cluster infrastructure namespaces (for example kube-system), CNI plugins, or monitoring agents that genuinely require host access.
The image outlines the first of three security levels, labeled "Privileged." It describes the level as having maximum risk with no restrictions, allowing pods extensive actions such as running as root and accessing the host network.
  • Baseline — the recommended default for most application namespaces. Baseline blocks dangerous host-level privileges (for example, hostNetwork, hostPID, privileged containers) while remaining compatible with typical containerized applications.
The image depicts a diagram of three security levels: Privileged, Baseline, and another unspecified level, with a focus on the Baseline level, which describes its moderate risk and security features for typical web apps and microservices.
  • Restricted — the strictest profile. Restricted includes Baseline restrictions and additionally requires pods to run as non-root users, disables privilege escalation, limits Linux capabilities, and encourages read-only root filesystems and selinux/seccomp profiles where appropriate. Use Restricted for sensitive workloads that must satisfy strong runtime controls.
The image shows a diagram of three security levels labeled as Privileged, Baseline, and Restricted, with details under Restricted about minimizing risk and maximizing security.
Key guidance: use baseline as your default for application namespaces, restricted for high‑security workloads, and privileged only where host access is required.
The image is a table showing the configurations blocked at each security level (Privileged, Baseline, Restricted) for pod specifications, such as privileged containers, host networking, and running as root.
Memorize the distinction: Baseline prevents dangerous host access; Restricted additionally locks down the container runtime and user/privileges.

​
Enforcement modes — how to apply the levels

PSS supports three independent enforcement modes that you can set per namespace. Best practice is to stack modes so teams can iterate toward stricter profiles without breaking running workloads.
  • enforce — hard blocker. Pods that violate the specified level are rejected during admission.
  • audit — log only. Violations are recorded in audit logs but pods are allowed.
  • warn — user-visible warning. Pods are allowed, but API responses include a warning message.
A common pattern: enforce baseline to immediately block host-level risks, and use audit/warn for restricted so teams can remediate before you enable enforcement.
The image illustrates three enforcement modes: "Enforce" (hard block), "Warn" (visible warning), and "Audit" (silent logging), for handling pod violations. Each mode is depicted with a brief description of its function.
Recommended practice: Enforce baseline for all application namespaces. Use audit/warn at restricted to surface work needed to move workloads to the stricter profile without breaking them.

​
Applying Pod Security Standards with namespace labels

PSS is label-driven: no CRDs, no external admission controllers required. You apply levels and modes by labeling namespaces with the pod-security.kubernetes.io/* keys. Example labels:
To set these labels, use kubectl label. Example — apply restricted for enforce and warn on the payments namespace:
Verify labels:
You can also pin behavior to a specific API behavior version using pod-security.kubernetes.io/enforce-version (for example v1.27) or set it to latest. If omitted, the cluster default behavior is used.
The image is a guide for applying PSS namespace labels in Kubernetes, detailing label format with specific prefixes, modes, and levels.
Do not casually label core system namespaces (for example kube-system) as restricted or baseline unless you’ve validated operator and add-on compatibility. Mislabeling control-plane or infrastructure namespaces can break cluster components.

​
PSS vs Gatekeeper / Kyverno

PSS provides a zero-install baseline covering critical pod-level security fields. It is intentionally limited in scope. For organization-specific constraints you should layer a policy engine.
  • PSS: built-in, minimal setup, enforces core runtime controls.
  • Gatekeeper / Kyverno: support complex, custom policies (for example, image registries, required labels, resource quotas, mutation, multi-field constraints).
Use PSS as the mandatory floor across all namespaces, then add Gatekeeper or Kyverno for additional operational policies.
The image is a comparison chart of PSS, Gatekeeper, and Kyverno, highlighting aspects such as installation, scope, granularity, mutation, and use cases. It suggests using PSS as a baseline with Gatekeeper or Kyverno for custom policies.

​
Summary / Key takeaways

  • PSS levels: privileged (most permissive), baseline (recommended default), restricted (most restrictive).
  • Enforcement modes per-namespace: enforce (block), audit (log), warn (inform). Stack modes so teams can migrate safely.
  • PSS uses namespace labels only—no installation required. Use kubectl label to manage them and consider enforce-version when pinning behavior.
  • For restricted compliance, important settings include running as non-root, disabling privilege escalation, minimizing capabilities, enforcing seccomp, and using a read-only root filesystem where feasible.
  • Treat PSS as your baseline safety net and layer Gatekeeper or Kyverno for organization-specific policies.
The image outlines four key security takeaways related to pod security levels, modes, namespace label application, and settings for restricted pods.

Watch Video