In this lesson, you will learn how to identify existing, non-compliant Pods within your cluster using the audit mode of Pod Security Admissions without triggering immediate disruptions.
The Challenge of Enforcement
When you transition from a "loose" security posture to a strict one, applying policies like restricted Pod Security Standards can be intimidating. If you enforce these policies immediately, any Pod currently running as root or using a mutable root filesystem would be flagged during creation, but what happens to the Pods that are already running? This is where Audit Mode becomes your primary tool for a smooth migration.
Leveraging Audit Mode
Pod Security Admissions allow you to apply labels to namespaces that dictate how the API server handles security checks. Instead of enforce mode—which rejects non-compliant Pods—audit mode allows the Pod to run while recording a warning in the Kubernetes audit logs.
To set a namespace to audit mode, you apply a label to the namespace. For example, to audit against the restricted profile, run:
kubectl label namespace <namespace-name> \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/enforce=privileged
In this configuration, your cluster continues to allow privileged workloads to run (because the enforce mode is set to privileged), but it simultaneously watches all incoming requests against the restricted standard.
Identifying Violations
Once audit mode is active, any Pod that violates the restricted security standard will trigger a warning log entry. You can view these events by examining your Kubernetes audit logs (often found via your cloud provider's logging tool or local audit.log file). This gives you a clear inventory of exactly which Pods need to be refactored or updated before you switch to actual enforcement.
By treating the audit logs as your "to-do list," you can systematically remediate security violations in a non-disruptive way. Once your audit logs show zero violations for a specific namespace, you can safely flip the enforce mode to restricted with confidence, knowing you won't break production services.
Key Takeaway: Use audit mode to surface security violations in your logs before applying strict enforcement, allowing you to secure your cluster through gradual, informed remediation rather than disruptive trial-and-error.