⌂ Home

Pod Security Standards

Interactive guide to Privileged, Baseline, Restricted profiles and enforce, audit, warn modes in Pod Security Admission.

Pod Security Admission replaced PodSecurityPolicy with a simpler namespace-label model. The real learning goal is understanding profile levels and enforcement modes together.

Core Model

Understand the Concept First

Three profiles

Privileged, Baseline, and Restricted define increasing levels of hardening.

Namespace-level labels

Pod Security Admission uses namespace labels to set desired policy behavior.

Three modes

enforce rejects, audit records, and warn notifies without blocking.

Security Profiles

Pod Security Standards Levels Comparison

Click on any security level to see detailed restrictions and allowed capabilities.
Privileged No Restrictions 🔓 ✓ Host namespaces allowed ✓ Privileged containers ✓ Host path volumes ✓ All capabilities ✓ Run as root ✓ Any user/group ID Use: System workloads Baseline Minimally Restrictive ⚠ïļ ✗ No privileged containers ✗ Limited host namespaces ✗ Limited capabilities ✗ No host path volumes ✓ Can run as root ✓ Any user/group ID Use: General applications Restricted Hardened Security 🔒 ✗ No privileged containers ✗ No host access ✗ All capabilities dropped ✗ Must run as non-root ✗ Drop ALL capabilities ✗ seccompProfile required Use: Security-sensitive apps
Security Progression: Privileged allows everything → Baseline blocks common escalations → Restricted enforces defense-in-depth hardening
Policy Enforcement

Pod Security Admission Flow

See how different enforcement modes affect pod admission outcomes.
Pod Request User submits Pod manifest API Server Receives request PSA Controller Checks namespace labels for policy Evaluate against: Security Profile ✓ Allowed Pod meets security standards ✗ Denied Pod violates security policy Enforce Mode Pods that violate the policy are rejected and not created.
Migration Strategy: Start with warn to see violations → Add audit to log them → Finally enable enforce when ready
Multi-Namespace Policies

Namespace Policy Visualization

Different namespaces can have different security policies. Click each namespace to see its configuration.
Kubernetes Cluster production (Restricted) 🔒 Labels: enforce: restricted audit: restricted warn: restricted Security Requirements: ✗ No privileged containers ✗ Must run as non-root ✗ Drop all capabilities Running Pods web-app non-root user api-server seccomp enabled database read-only root Best Practices â€Ē Use restricted for production workloads â€Ē Use baseline for development/staging â€Ē Reserve privileged for system namespaces â€Ē Test with warn/audit before enforce â€Ē Document exceptions explicitly

Privileged vs Restricted

Feature Privileged Restricted
Root user ✓ ✗
Host access ✓ ✗
Capabilities All None
Seccomp Optional Required
Lifecycle Flow

Namespace Policy Enforcement Flow

1

Label namespace

Set enforce, audit, and warn levels through namespace labels.

2

Submit Pod or workload

A user creates a Pod or a controller creates one on the namespaceâ₮â„Ēs behalf.

3

Admission checks profile

Kubernetes compares the workload against the selected security profile.

4

Allow, warn, or reject

The request outcome depends on which mode is configured.

The most useful migration path is often to start with warn or audit before moving to strict enforce mode.
YAML and Commands

Examples You Can Recognize Quickly

Namespace Labels
pod-security.kubernetes.io/enforce=restricted
pod-security.kubernetes.io/audit=baseline
pod-security.kubernetes.io/warn=baseline
Useful Commands
kubectl label namespace pss-restricted pod-security.kubernetes.io/enforce=restricted
kubectl get ns --show-labels
Decision Guide

Profile Comparison

Profile Security posture Typical use
Privileged Minimal restriction Trusted system workloads
Baseline Blocks common privilege escalation risks General application workloads
Restricted Strong hardening expectations Security-sensitive namespaces
Restricted is the most secure profile, but Baseline is often the practical stepping stone for many existing workloads.
Use It Well

Practice and Real-World Thinking

Namespace hardening

Set different security levels for dev, shared, and critical namespaces.

Migration planning

Use warn and audit to discover what would break before enforcing.

Security review

Combine PSA with container security context design for better results.