Kubernetes Pod Security Admission Modes

Kubernetes Pod Security Admission Modes are the three independent enforcement behaviors — enforce, audit, and warn — that the built-in PodSecurity admission controller supports for applying a Pod Security Standard to a namespace, each triggered by its own namespace label and each producing a distinct response when a pod violates the configured standard. Understanding how these modes differ, and how they combine, is central to rolling out pod security policy without unexpected disruption.

The Three Modes Individually

enforce

The enforce mode is the only mode that actually blocks non-compliant pods; a CREATE or UPDATE request for a pod violating the standard set in pod-security.kubernetes.io/enforce is rejected outright by the API server, and the client receives an error explaining which requirement was violated.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted

kubectl apply -f privileged-pod.yaml -n payments
# Error from server (Forbidden): pods "app" is forbidden: violates PodSecurity "restricted:latest": ...

audit

The audit mode allows a non-compliant pod to be created, but records the violation as an annotation in the Kubernetes audit log, making it useful for understanding the scope of non-compliance across a namespace without blocking any workload while that assessment happens.

metadata:
  labels:
    pod-security.kubernetes.io/audit: restricted

warn

The warn mode also allows the pod through, but returns a human-readable warning message directly to the client issuing the request (visible in kubectl output), giving the pod's author immediate, actionable feedback without requiring them to separately inspect audit logs.

kubectl apply -f pod.yaml -n payments
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false
pod/app created

Combining Modes on a Single Namespace

Independent Standards Per Mode

Each mode can be set to a different standard on the same namespace — for instance, enforcing baseline while auditing and warning against restricted — which lets a namespace maintain a strict minimum bar immediately while surfacing what would additionally be required to reach a stricter target standard.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Version Suffixes Per Mode

Each mode label has a corresponding -version label (enforce-version, audit-version, warn-version) that pins the standard's definition to a specific Kubernetes release, defaulting to the version the API server is currently running if omitted; pinning avoids the enforced rule set silently changing as the cluster is upgraded to a newer minor version.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.29

Using Modes Together for Staged Rollout

The Standard Migration Pattern

A widely used adoption sequence sets audit and warn to the target standard first while leaving enforce at the current, looser standard (or unset), observes accumulated audit log entries and developer-visible warnings over a representative period, remediates the non-compliant workloads surfaced, and only then raises enforce to match.

# Step 1: observe without blocking
kubectl label namespace payments \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted --overwrite

# Step 2: after remediation, enforce
kubectl label namespace payments \
  pod-security.kubernetes.io/enforce=restricted --overwrite

Reading Warnings in CI Pipelines

Because warn mode output appears in the standard client response, CI pipelines that apply manifests through kubectl can capture and fail on the presence of pod security warnings proactively, catching non-compliant manifests before merge even in namespaces where enforce has not yet been raised to the same standard.

Practical Considerations

Modes Only Apply Going Forward

None of the three modes retroactively evaluate pods that already exist; a pod created before a namespace's labels were set (or before they were tightened) is not re-evaluated until it is next created or updated, meaning audit and warn findings reflect new activity, not necessarily the full current population of running pods.

Choosing enforce Without audit or warn

Setting only enforce without first observing via audit or warn is possible and sometimes appropriate for a brand-new namespace with no legacy workloads, but for an existing namespace it risks blocking legitimate, already-functioning deployments the moment they are next updated, without any prior signal to the teams responsible for them.