Unlabelled Namespaces Inherit PodSecurity's Privileged Default

The Trap

Namespace-scoped PodSecurity enforcement without a hardened cluster-wide default. PodSecurity Admission decides what a namespace permits by reading its pod-security.kubernetes.io/enforce label, but that label is optional per namespace. If the label is absent, the admission plugin falls back to whatever defaults.enforce value the API server was given at startup — and if nobody supplied an AdmissionConfiguration file, that value is “privileged”.

The Default State

Since Kubernetes 1.25, the PodSecurity admission plugin is compiled into kube-apiserver and listed in –enable-admission-plugins by default, so security tooling that only checks whether the plugin is loaded reports a clean pass. Operators then label the two or three namespaces they consciously hardened — usually production workloads — and assume the rest inherit something safe. They don’t. Namespaces created by Helm releases, Terraform kubernetes_namespace resources, GitOps reconcilers, and CI pipelines spinning up per-branch preview environments almost never carry the enforce label, because nobody writes it into the chart template. Each of these lands on the cluster’s implicit default, which without an explicit AdmissionConfiguration file is “privileged:latest” for enforce, audit and warn alike — the equivalent of no PodSecurity Admission at all.

The Blast Radius

A pull-request preview namespace spins up with a container spec setting privileged: true and hostPID: true. PodSecurity Admission admits it silently because the namespace was never labelled and the cluster default permits it. The container mounts the host filesystem, reads the node’s kubelet credentials from /var/lib/kubelet, and queries the cloud instance metadata service for the node’s IAM role. From there it reaches the kubelet API on port 10250, lists every pod on the node, and extracts service account tokens for workloads with far broader RBAC than the preview environment was ever meant to have. Nothing alerts, because admission never fired a denial — there was no policy configured to violate.

The Lead Mechanic Fix

Ship an explicit AdmissionConfiguration and stop relying on the compiled-in default. Set defaults.enforce and defaults.audit to baseline or restricted, pin enforce-version to latest, and list only genuine exemptions by name:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
– name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: “baseline”
      enforce-version: “latest”
    exemptions:
      namespaces: [“kube-system”]

Restart kube-apiserver with –admission-control-config-file pointing at that manifest, then bind a ValidatingAdmissionPolicy that rejects any namespace CREATE lacking pod-security.kubernetes.io/enforce set to baseline or restricted, closing the gap the label alone leaves open.