PodSecurity Admission's Silent Privileged Default
When PodSecurityPolicy is removed but namespaces aren't labelled for Pod Security Admission, Kubernetes falls back to the privileged profile cluster-wide. New namespaces created by CI pipelines or Helm inherit no restriction at all, and admission logs show clean passes because privileged pods are permitted by design.
Operational summary
At a glance
- Symptom
- A namespace created without an enforce label admits a pod requesting privileged mode, hostPID, or a hostPath mount.
- Likely cause
- Namespaces left without pod-security.kubernetes.io labels after PodSecurityPolicy removal.
- Impact
- Unlabelled namespaces default to the privileged profile, permitting container escape and lateral movement with no admission denial logged.
- Verification signal
- Re-run the detection test and a controlled negative-path test.
- Safe correction
- Set a cluster-wide restricted default via AdmissionConfiguration and enforce label presence on namespace creation with a validating policy.
- Rollback or recovery
- Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
The Trap
Decommissioning PodSecurityPolicy at the 1.25 removal deadline and adopting the built-in PodSecurity admission (PSA) controller without labelling every namespace explicitly. Teams treat PSA migration as complete once a handful of audited namespaces carry the pod-security.kubernetes.io/enforce label, leaving everything else to whatever the cluster falls back to.
The Default State
Any namespace without pod-security.kubernetes.io/enforce, audit, or warn labels is evaluated against the compiled-in default, which is privileged for all three modes unless overridden via an AdmissionConfiguration file. PSP enforced a deny-by-default posture; PSA enforces nothing unless a label says otherwise. Migration scripts typically label production namespaces flagged during a PSP audit and stop there. CI-generated ephemeral namespaces, new team namespaces, and anything created after the migration window inherit no restriction whatsoever.
The Blast Radius
A branch-deploy pipeline creates a namespace via Helm without the enforce label. A pod manifest requests privileged: true, hostPID: true, and a hostPath mount of /var/lib/kubelet/pods. PSA admits it silently — the privileged profile permits all of this, so no audit annotation, no warning event, nothing for SIEM rules keyed on admission denials to catch. From that pod the attacker reads service account tokens mounted for every other pod scheduled on the node, escapes via the host mount namespace, and pivots to any node sharing the same worker pool image, since NetworkPolicy objects were never reinstated either. Security teams report PSA as “deployed” based on label coverage in the handful of namespaces they checked, while the actual enforcement surface across the cluster is unchanged from having no policy engine at all.
The Lead Mechanic Fix
Set a cluster-wide default via the kube-apiserver --admission-control-config-file pointing to a PodSecurityConfiguration with defaults.enforce: restricted and explicit exemptions.namespaces for kube-system, kube-node-lease, and kube-public only. Backfill existing namespaces with kubectl label ns --all pod-security.kubernetes.io/enforce=baseline pod-security.kubernetes.io/enforce-version=v1.29 --overwrite, pinning the version to stop silent policy drift on cluster upgrades. Then block the gap permanently with a Kyverno ClusterPolicy or ValidatingAdmissionPolicy that rejects namespace creation lacking the enforce label, so no namespace can exist in the unlabelled privileged state again.
Apply the safer control
Before you change production
Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.
Fix commands and configuration
--admission-control-config-filePodSecurityConfigurationdefaults.enforce: restrictedVerify, roll back or escalate
Verify
Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.
Rollback
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
Escalate
Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.