A Namespace Label Typo That Lets Pod Security Admission Silently Allow Privileged Pods

Symptom

A namespace intended to enforce the restricted Pod Security Standard accepts a pod manifest requesting privileged: true and hostPath mounts without any admission rejection. kubectl apply returns success, the pod reaches Running, and no warning or audit annotation appears. The team believes Pod Security Admission (PSA) is active because the namespace YAML clearly lists the enforce label alongside other labels, and a similar namespace in the same cluster does correctly block privileged pods.

The immediate observation is narrow: enforcement is present for other namespaces and absent for this one, with no error surfaced at apply time.

False Assumption

The operator assumes that any namespace containing a pod-security.kubernetes.io/enforce key in its labels is protected, and that a successful kubectl apply -f namespace.yaml proves the label was accepted and understood by the API server. Kubernetes label keys and values are opaque strings to the object store; the admission controller only matches the exact key pod-security.kubernetes.io/enforce and only recognises exact values privileged, baseline or restricted. A namespace apply succeeds even if the key is misspelled (for example pod-security.kubernetes.io/enforced) or the value contains a typo or trailing whitespace (for example Restricted or restricted ), because label validation only checks that keys and values conform to generic Kubernetes label syntax, not that they match a controller’s expected vocabulary.

Root Cause

Pod Security Admission is a built-in admission webhook that reads specific well-known label keys on the Namespace object at request time. If the enforce label key is misspelled, uses the wrong case, or the value does not exactly match one of the three defined levels, PSA treats the namespace as having no enforce mode configured for that mode and falls through to the cluster default, which is typically privileged (no restriction) unless a cluster-wide PodSecurity admission configuration sets a stricter default. The namespace manifest is syntactically valid Kubernetes YAML, so kubectl apply, static YAML linting and generic policy-as-code checks that only validate label syntax will not catch the mismatch. The failure is deceptive because the operator can visually scan the namespace definition, see a label that looks correct, and reasonably conclude protection is active.

Impact

Any workload deployed into the affected namespace can request privileged containers, hostPath volumes, host networking or hostPID/hostIPC without admission-time rejection, which materially increases the blast radius of a compromised container or a misconfigured deployment pipeline that targets the wrong namespace. This is a silent control gap: no alert fires, no admission event is logged, because from the API server’s perspective enforcement was never configured for that namespace in the first place.

Diagnosis

Confirm the namespace’s actual applied labels rather than the source YAML, since the source file and the live object can diverge, and because visual inspection of YAML cannot reveal a value with trailing whitespace or a case mismatch.

1. Retrieve the live namespace labels directly from the API server, not from the manifest file on disk.
2. Compare the exact key and value against the three PSA-recognised levels: privileged, baseline, restricted.
3. Attempt a dry-run apply of a manifest that should be rejected under restricted (for example a pod requesting privileged: true) using --dry-run=server, which exercises the real admission chain without creating a persistent object.
4. Check whether a cluster-wide PodSecurityConfiguration admission plugin config sets a different default enforce level, which changes the fallback behaviour when a namespace label is absent or malformed.

Correction

Correct the namespace label to the exact recognised key and one of the three exact recognised values, then re-verify enforcement with a server-side dry run before relying on it in production. Do not assume the fix is complete once the label text visually matches; re-run the dry-run rejection test to get positive confirmation from the admission controller itself.

Validation

Validation succeeds only when a server-side dry run of a manifest that violates the intended Pod Security Standard is rejected with an explicit PSA violation message referencing the correct enforce level.

1. Run a server-side dry-run apply of a manifest requesting privileged: true against the corrected namespace and confirm the API server returns an admission denial citing the restricted (or intended) policy.
2. Run the same dry run against a namespace known to be correctly configured and confirm the denial message format matches, to rule out a coincidental unrelated rejection.
3. Retrieve the namespace object again and confirm the label key and value are byte-for-byte one of the three recognised strings, with no trailing whitespace or case variation.

Rollback

If the corrected label unexpectedly blocks a workload that must continue running while the workload itself is remediated, do not disable Pod Security Admission cluster-wide. Instead, temporarily set the namespace’s enforce level to a less restrictive but still defined value such as baseline, and set the audit and warn labels to restricted so violations remain visible without blocking traffic, then track remediation of the underlying workload separately.

Prevention

Add a policy-as-code check to CI/CD that queries the live namespace object (not the source manifest) after apply and asserts the enforce label matches one of the three exact recognised values, so environment drift or apply-order issues are caught immediately. Include a scheduled server-side dry-run rejection test against a known-bad manifest as a synthetic monitor, since this exercises the actual admission behaviour rather than trusting label presence alone. Treat any namespace lacking a passing synthetic rejection test as unprotected regardless of what its labels appear to say.