A Pod Security Admission Namespace Label That Silently Waives Enforcement

Symptom

A platform team applies Pod Security Admission (PSA) labels to a namespace expecting the ‘restricted’ or ‘baseline’ enforcement level to block privileged workloads. Pods that request host networking, host path mounts or privileged security contexts are created without any admission rejection, and no warning or audit event appears in the API server logs for the affected namespace, even though other namespaces with apparently identical labelling correctly reject the same manifests.

False Assumption

The team assumes that setting pod-security.kubernetes.io/enforce=restricted on a namespace is sufficient on its own to guarantee enforcement, and that the presence of this label is the only condition PSA evaluates. This assumption ignores that PSA also reads separate warn and audit mode labels independently, and that a namespace-level pod-security.kubernetes.io/exempt label, or cluster-wide exemption configured in the AdmissionConfiguration for specific namespaces, usernames or runtimeClasses, takes precedence over the enforce label for matching requests.

Root Cause

Kubernetes documentation on Pod Security Admission describes exemptions as evaluated before mode labels are applied: if a request matches any configured exemption (by namespace, authenticated username, or runtimeClassName) it is allowed regardless of the enforce level set on the namespace. In this trap, a namespace was added to the cluster’s static AdmissionConfiguration exemption list during an earlier migration to unblock a legacy controller, and that exemption was never removed after the controller was retired. The namespace-level enforce label was added later by a different team member who was unaware the cluster-wide exemption already covered that namespace, so the label had no effect. Kubernetes’ own debugging documentation confirms that workload behaviour must be verified against the live admission chain rather than assumed from labels alone (source: Kubernetes, ‘Debugging Applications’).

Impact

Privileged or host-mounting pods can be scheduled in a namespace that appears hardened, undermining the intended blast-radius containment for that workload tier. Any workload relying on the namespace boundary as a control point, including audit and compliance evidence based on the enforce label, is materially inaccurate until the exemption is identified and removed.

Diagnosis

Confirm the live admission configuration rather than trusting namespace labels alone.

• Inspect the namespace labels to confirm the intended enforce, warn and audit levels are present.
• Retrieve the API server’s AdmissionConfiguration file (or the equivalent AdmissionConfiguration object if managed via a control-plane operator) and inspect the PodSecurity plugin’s exemptions block for namespaces, runtimeClasses and usernames.
• Cross-reference the namespace under investigation against the exemption list.
• Attempt to create a deliberately non-compliant test pod manifest (privileged: true) in a scratch copy of the namespace naming pattern, in an isolated test cluster, to observe whether admission rejects it.

Correction

Remove the stale namespace exemption from the AdmissionConfiguration so the existing enforce label takes effect as intended.

1. Take a copy of the current AdmissionConfiguration file before editing it.
2. Edit the PodSecurity plugin configuration to remove the retired namespace from the exemptions.namespaces list, leaving other legitimate exemptions untouched.
3. Apply the updated AdmissionConfiguration to the control plane through the cluster’s documented mechanism (static pod manifest reload or managed control-plane update process), following the platform’s change process.
4. Re-run the test pod creation from the diagnosis step against the corrected namespace and confirm admission now rejects the privileged manifest with a PodSecurity violation message.

Validation

Validation succeeds only when a deliberately non-compliant pod manifest is rejected by admission control in the corrected namespace and the rejection is visible in API server audit logs.

• Submit a test manifest requesting privileged: true and confirm the API server returns an admission-denied error referencing the PodSecurity policy.
• Query the API server audit logs (or the audit backend configured for the cluster) for the corresponding admission review and confirm it shows allowed: false with the PodSecurity reason.
• Repeat the same test manifest against a known-compliant namespace to confirm consistent behaviour across the cluster, not just the corrected namespace.
• Confirm no other workloads in the corrected namespace were disrupted by checking pod status and recent events for unexpected restarts or scheduling failures.

Rollback

If removing the exemption blocks a workload that still legitimately depends on it, restore the previous AdmissionConfiguration from the pre-change copy and re-apply it through the same documented control-plane update mechanism used for the correction.

• Stop condition: any workload in the corrected namespace fails to schedule or is evicted immediately after the AdmissionConfiguration change, and the failure is confirmed (via pod events) to be a PodSecurity admission denial rather than an unrelated scheduling issue.
• Rollback action: reapply the saved original AdmissionConfiguration file, then confirm via the diagnosis test manifest that the namespace has returned to its prior admission behaviour.
• Do not delete or recreate the namespace as part of rollback; only the AdmissionConfiguration file should be reverted.
• Escalate to the platform security owner before re-adding any namespace exemption permanently, and document the business justification if the exemption is genuinely still required.

Prevention

Treat AdmissionConfiguration exemptions as first-class security state requiring the same change review as namespace labels, not as a one-off migration artefact. Maintain an inventory of active exemptions with an owner and expiry review date for each entry, and include an exemption-list check in periodic cluster security audits. When onboarding new namespace owners, document that namespace labels are necessary but not sufficient evidence of enforcement, and require confirmation against the live AdmissionConfiguration before treating a namespace as hardened.