Pod Security admission: roll out enforce, audit and warn safely

Pod Security admission is configured with namespace labels. Set audit and warn first at the level you want, read what would fail, fix the manifests, then add enforce. Enforce rejects violating pods, audit records them in the audit log, and warn shows the user a message. The feature has been stable since Kubernetes v1.25.

The labels

Each mode uses a label of the form pod-security.kubernetes.io followed by the mode, with a level of privileged, baseline or restricted. You can also pin a policy version.

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

A namespace can combine modes, and each can use a different level. The example above blocks only Baseline violations but reports Restricted ones.

What each mode does

Enforce: violations cause the pod to be rejected.

Audit: violations add an annotation to the audit log event. The request is allowed.

Warn: violations show a warning to the user. The request is allowed.

A rollout in four steps

1. Add warn and audit at Restricted on one namespace. Deploy as usual.
2. Collect the warnings in CI output and the audit annotations. Group them by cause, such as missing runAsNonRoot or no dropped capabilities.
3. Fix the manifests or images. Re-test.
4. Add enforce at the highest level that passes. Repeat for the next namespace.

Start with low-risk namespaces and work toward the most critical, so the first rejection is not in production.

The Deployment caveat

The docs say audit and warn apply to workload resources such as Deployments and Jobs, which gives early feedback. Enforce does not. It applies to the Pod objects a controller creates from the template. So a Deployment can be accepted while its pods are rejected. Watch ReplicaSet events when a rollout stalls.

Exemptions

Exemptions are set statically in the admission controller configuration, by username, runtime class or namespace. Matching requests skip enforce, audit and warn entirely. The docs advise against exempting controller service accounts, since that would implicitly exempt anyone who can create the matching workload. Keep the list short and review it.

For a view of what each level requires, see Kubernetes Pod Security Standards: Baseline vs Restricted.

What to record

Keep a short table per namespace with the current enforce level, the target level, the blockers and an owner. Update it as you go. When the table shows every application namespace at its target, schedule a review of the exemption list and the namespaces left at Privileged. Treat each as an exception that needs a reason.

Quick check

Sources

• Pod Security Admission, Kubernetes documentation

Last reviewed: 19 October 2026.