Pod Security Policy vs Pod Security Standard: Key Differences and Usage

The Pod Security Policy (PSP) is a deprecated Kubernetes feature that controlled pod security via cluster-wide policies, while the Pod Security Standard (PSS) is the modern replacement using built-in admission controls with predefined security levels. PSS is simpler, built-in, and recommended for enforcing pod security in Kubernetes 1.22 and later.

Quick Comparison

This table summarizes the main differences between Pod Security Policy and Pod Security Standard.

Aspect	Pod Security Policy (PSP)	Pod Security Standard (PSS)
Status	Deprecated since Kubernetes 1.21, removed in 1.25	Built-in since Kubernetes 1.22, actively supported
Implementation	Custom resource and admission controller	Built-in admission controller with predefined profiles
Configuration	Complex YAML policies with many options	Simple labels on namespaces with three security levels
Security Levels	Highly customizable, user-defined	Three fixed levels: privileged, baseline, restricted
Ease of Use	Complex to configure and maintain	Easy to apply and audit
Flexibility	Very flexible but complex	Less flexible but covers common use cases

Key Differences

Pod Security Policy was a Kubernetes resource that allowed cluster administrators to define detailed rules about what pods could do, such as running as root, using host networking, or mounting volumes. It required creating and managing custom YAML policies and binding them to users or service accounts. PSP was powerful but complex and hard to maintain, leading to its deprecation.

In contrast, Pod Security Standard is a simpler, built-in admission controller that enforces pod security by labeling namespaces with one of three predefined security levels: privileged, baseline, and restricted. These levels cover common security needs without complex policy definitions. PSS is easier to use, audit, and is the recommended approach for Kubernetes versions 1.22 and later.

While PSP allowed fine-grained control, it required more effort and was prone to misconfiguration. PSS trades some flexibility for simplicity and better integration with Kubernetes native features, making pod security easier to enforce consistently.

Code Comparison

Here is an example of a simple Pod Security Policy that restricts pods from running as root and using host networking.

yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted-psp
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
    - configMap
    - emptyDir
  hostNetwork: false
  hostIPC: false
  hostPID: false

Output

PodSecurityPolicy resource created to restrict root user and host networking

Pod Security Standard Equivalent

The equivalent Pod Security Standard setup uses namespace labels to enforce the restricted level, which disallows running as root and host networking by default.

bash

kubectl label namespace my-namespace pod-security.kubernetes.io/enforce=restricted
kubectl label namespace my-namespace pod-security.kubernetes.io/enforce-version=v1.24

Output

namespace/my-namespace labeled

When to Use Which

Choose Pod Security Standard when you want a simple, built-in, and supported way to enforce common pod security policies with minimal setup and maintenance. It is ideal for most clusters running Kubernetes 1.22 or newer.

Use Pod Security Policy only if you maintain legacy clusters that still require fine-grained, custom pod security controls and cannot upgrade to newer Kubernetes versions. However, migrating to PSS or other solutions is recommended as PSP is deprecated and removed.

Key Takeaways

Pod Security Policy is deprecated; use Pod Security Standard for modern Kubernetes pod security.

Pod Security Standard uses simple namespace labels with three fixed security levels.

PSP offers fine-grained control but is complex and removed in recent Kubernetes versions.

PSS is easier to use, audit, and integrates natively with Kubernetes admission controls.

Choose PSS for new clusters and migrate from PSP to maintain security and support.