Enforcement via Namespace Labels
PSA is activated by adding specific labels to a Namespace. No separate controller installation is needed — PSA is built into the API server as of Kubernetes v1.23 (stable in v1.25).
Each label follows the pattern pod-security.kubernetes.io/<MODE>: <LEVEL>, with a companion pod-security.kubernetes.io/<MODE>-version: <VERSION> label. <MODE> is one of three enforcement modes, <LEVEL> is one of the three PSS profiles, and <VERSION> pins the policy to a specific Kubernetes version (for stability across upgrades).
The Three Enforcement Modes
enforce: The Pod is rejected if it violates the policy. The API server returns an error and the Pod is never created. This is the hard gate.
audit: The Pod is allowed, but a violation is recorded in the Kubernetes audit log. Useful for discovering what would break before enabling enforce.
warn: The Pod is allowed, but the user sees a warning message in their terminal immediately after running kubectl apply. Useful for developer feedback without blocking deployments.
The three modes are independent and can be combined. A common migration pattern is:
- Start with
warn: restricted— developers see warnings but nothing breaks. - Add
audit: restricted— violations appear in audit logs for monitoring. - After fixing violations, add
enforce: restricted— hard enforcement begins.
All three modes can be set on the same Namespace at once, each pinned to the same PSS profile and Kubernetes version — enforce rejecting non-compliant Pods outright, audit recording violations for monitoring, and warn surfacing terminal warnings to developers.
Exemptions
PSA supports exemptions for specific usernames, RuntimeClasses, or Namespaces — configured at the API server level. This allows system components (like the CNI plugin's DaemonSet) to be exempted from namespace-level policies without switching the entire namespace to Privileged.
Interviewers often ask: "How would you migrate a cluster from PodSecurityPolicy to Pod Security Admission without causing downtime?" The correct answer describes a phased approach: first audit existing PSPs to determine the effective policy level per namespace, then label namespaces with warn and audit modes at the target PSS level, fix any violations surfaced by warnings and audit logs, and only then switch to enforce. This demonstrates understanding of both the technical mechanism and the operational risk of a hard cutover.