Pod Security Admission audit and warn do not enforce the policy

Kubernetes Pod Security Admission can evaluate Pods against the Pod Security Standards. Its three modes, enforce, audit, and warn, are related but not interchangeable. A namespace with an audit label is not a namespace that blocks a privileged Pod.

The Kubernetes documentation says enforce rejects Pods that violate the selected policy. audit adds audit annotations and events while allowing the request, and warn returns a warning to the client while allowing the request. Both are useful for discovery and rollout. Neither becomes an admission denial by itself.

This distinction matters because operators often deploy a policy in warn mode, review the warnings during a change window, and then assume the policy remains active. It does not. If the enforce label is missing, empty, or set to a weaker level, the object can still be admitted. Verification must inspect the effective namespace labels and test a deliberately violating manifest.

Version selection adds another ambiguity. A namespace can pin the policy version for enforce, audit, and warn separately. The documentation recommends running audit and warn at the same level as enforce but at the latest version to see drift from current expectations. A pinned older version may intentionally allow behavior that a newer policy would reject. That is a maintenance decision, not evidence that the policy has current coverage.

Exemptions also skip all three modes. The admission controller ignores requests that match its configured exemptions. A user who sees successful policy checks should confirm that the namespace, user, and runtime class are not exempt. Exemptions are sometimes necessary for control-plane workloads, but they need an owner, a reason, and a review date.

A practical validation sequence looks like this:

• Read the namespace's pod-security.kubernetes.io/enforce label and record its level and version.
• Create a dry-run or disposable Pod that violates the level and confirm rejection.
• Check the audit annotation and event path separately.
• Check warning delivery through the same API client used by deployment automation.
• Review exemptions and identify every namespace that can bypass the check.

Policy quality matters as much as mode. The restricted standard covers a stronger set of controls than baseline, but it cannot express every organization-specific rule. A separate admission policy may be needed for image provenance, approved registries, or required labels. Those rules should be tested against the Pod Security Admission result rather than assumed to be part of it.

Pod Security Admission is useful because it gives cluster operators a built-in control. It becomes a real control only when enforce is active, the version is deliberate, exemptions are audited, and a violating workload fails the path that deployment automation actually uses.

References

• Kubernetes: Pod Security Admission
• Kubernetes: Enforcing Pod Security Standards