Skip to main content
Pod Security Standards (PSS) are Kubernetes’ built-in runtime controls that limit what Pods can do. Unlike policy tools such as Gatekeeper or Kyverno, PSS requires no installation — it is enforced by the API server via the Pod Security admission controller. PSS replaced the deprecated PodSecurityPolicy (removed in Kubernetes v1.25). This guide explains the three security levels, how enforcement modes work and stack, and how to enable PSS using only namespace labels.
A presentation slide titled "Learning Objectives." It lists four numbered goals about Kubernetes Pod Security, including security levels (Privileged/Baseline/Restricted), enforcement modes (enforce/audit/warn), namespace label configuration, and restricted pod compliance.

​
Security levels (from permissive to restrictive)

PSS defines three levels that control pod runtime privileges and capabilities. Choose the level that matches the trust and requirements of each namespace.

​
1) Privileged

  • Most permissive — no PSS runtime restrictions.
  • Pods may use host network, bind to host PID, run privileged containers, or run as root.
  • Intended only for system infrastructure that genuinely needs host access (for example kube-system, CNI plugins, or low-level monitoring agents).
A presentation slide titled "Three Security Levels" showing three numbered security-tier icons on a horizontal timeline, with the first tier highlighted as "Privileged." The left column lists details for Privileged access (maximum risk, no restrictions, pods can run as root) and example uses like system-level infrastructure.

​
2) Baseline

  • Safe default for most namespaces and most applications.
  • Blocks dangerous host-level capabilities such as host networking, host PID, privileged containers, and host mounts.
  • Many applications run on Baseline unchanged, though they may still run as root unless other controls restrict them.
A presentation slide titled "Three Security Levels" showing three tiers (Privileged, Baseline, and a third level) with the Baseline level highlighted. Under Baseline are short notes like "Moderate risk," "Prevents known privilege escalations," and recommendations for typical web apps.

​
3) Restricted

  • Maximum lockdown — includes Baseline restrictions plus stricter runtime constraints.
  • Requires containers to run as non-root, drop most capabilities, prefer read-only root filesystems, and use a seccomp profile.
  • Use for high-assurance or sensitive workloads; applications may need modification to comply.
A slide titled "Three Security Levels" showing a horizontal timeline with three tiers: 01 Privileged, 02 Baseline, and 03 Restricted. The Restricted column is expanded with notes like "Minimum risk," "Maximum security," requirements (non-root, drop all capabilities, read-only root filesystem) and use cases for sensitive workloads.

​
Quick comparison

Key guidance:
  • Use Baseline as the default for most namespaces.
  • Use Restricted for workloads that require strict runtime guarantees.
  • Use Privileged only for components that truly require host access.
Remember: Baseline prevents dangerous host-level access; Restricted additionally locks down the container runtime.

​
Enforcement modes — Enforce, Audit, Warn

PSS supports three independent modes that you can set per namespace and per mode:
  • Enforce — hard blocker: pods that violate the policy are rejected by the API server.
  • Audit — silent logging: violations are recorded for review, but pods are allowed.
  • Warn — admission warnings: pods are allowed and the API server returns a visible warning message.
A practical adoption pattern is to Enforce Baseline (to block risky host-level access) while setting Audit and/or Warn at Restricted. That allows teams to see what would be rejected under Restricted and remediate without breaking workloads immediately.
The image is a colorful circular infographic titled "Three Enforcement Modes" that outlines three Kubernetes policy modes: Enforce (hard block), Audit (silent logging), and Warn (visible warning). Each mode includes a short description about how pods are handled (rejected, allowed but logged, or allowed with a warning).

​
How to apply Pod Security Standards (namespace labels)

PSS is configured via namespace labels only — no CRDs or external webhooks required. You can set each mode independently (enforce, audit, warn) and pin a policy version if needed. Label format and examples: Example: enforce Baseline, audit and warn Restricted for the payments namespace
Verify the labels for a namespace:
List all namespaces and their labels:
A single kubectl label command is often all you need to start enforcing PSS for a namespace. Try this in a test namespace first to observe Audit/Warn output before switching to Enforce.

​
PSS vs Gatekeeper / Kyverno

PSS provides the zero-install runtime floor for Pod configuration. It intentionally focuses on runtime capabilities and host access. For policies PSS does not cover (for example requiring images from specific registries, enforcing custom labels, or applying complex mutations and organization-wide constraints), use a policy engine such as Gatekeeper or Kyverno.
An infographic table comparing PSS (built‑in), Gatekeeper, and Kyverno across categories like installation, scope, granularity, mutation, and when to use each. A banner at the bottom recommends using PSS as a baseline with Gatekeeper/Kyverno for custom policies.
Best practice: deploy PSS everywhere as the security floor and layer Gatekeeper or Kyverno policies on top for organization-specific rules and enforcement beyond runtime controls.
Pod Security Standards provide zero-install, cluster-wide protection for pod runtime configuration. Treat them as the baseline (floor) and use policy engines like Gatekeeper or Kyverno to enforce additional, higher-granularity rules.

​
Practical checklist for Restricted compliance

  • Run containers as a non-root user (runAsNonRoot: true).
  • Disallow privilege escalation (allowPrivilegeEscalation: false).
  • Drop unnecessary Linux capabilities (capabilities.drop: ["ALL"]).
  • Prefer read-only root filesystems (readOnlyRootFilesystem: true) where possible.
  • Use an appropriate seccomp profile (for example RuntimeDefault or a custom profile).

​
Summary / Key takeaways

  • Three PSS levels: Privileged (most permissive), Baseline (recommended default), Restricted (maximum lockdown).
  • Three modes: Enforce (rejects), Audit (logs), Warn (returns admission warnings). Modes are independent and stack.
  • Apply PSS with namespace labels — no additional installation required.
  • For higher-granularity or organizational policies (image sources, required labels, mutations), layer Gatekeeper or Kyverno on top of PSS.
A presentation slide titled "Key Takeaways" showing four numbered security points about privilege levels, enforcement modes, namespace labels, and restricted pod settings. The slide features a blue left panel with colorful numbered markers next to each takeaway.

Watch Video