Pod Security Standards enforcement at namespace level
Why it matters
Pod Security Standards (PSS) provide namespace-level policy enforcement that is evaluated before pod admission — without them, a misconfigured or malicious workload can deploy privileged containers, run as root, or mount host paths regardless of what individual securityContext fields are set (NIST 800-53 AC-3, CIS Kubernetes 5.2.1/5.2.6). PSS restricted blocks the entire class of misconfigurations — running as root, privilege escalation, host namespaces — at the namespace boundary. Individual securityContext checks on Deployments are necessary but not sufficient; without PSS, nothing prevents a developer from removing those fields.
Severity rationale
Low because PSS enforcement is a defense-in-depth control — its absence allows privileged pod deployment, but exploitation requires developer or CI-level cluster access.
Remediation
Label every application namespace with PSS enforcement labels. Apply via kubectl:
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/enforce-version=latest \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted
For namespaces running legacy workloads that cannot yet meet restricted, use baseline enforcement as an intermediate step:
kubectl label namespace legacy-ns \
pod-security.kubernetes.io/enforce=baseline
Run kubectl label namespace --dry-run=server ... first to see which existing pods would be rejected before enforcement goes live. PSS is built into Kubernetes 1.25+ — no additional admission controller installation required.
Detection
-
ID:
pod-security-standards -
Severity:
low -
What to look for: Enumerate every Kubernetes namespace that runs application pods. For each namespace, check for Pod Security Standards labels (
pod-security.kubernetes.io/enforce,pod-security.kubernetes.io/audit,pod-security.kubernetes.io/warn). Count the total application namespaces and how many enforce at least therestrictedorbaselinelevel. -
Pass criteria: Every namespace that runs application pods has Pod Security Standards labels set to at least
baselinelevel for enforcement, withrestrictedpreferred for production namespaces. At minimum 1 namespace usespod-security.kubernetes.io/enforce=restricted. Report: "X of Y application namespaces enforce Pod Security Standards." -
Fail criteria: Any application namespace lacks Pod Security Standards enforcement, or all policies are set to
privileged(unrestricted). -
Skip (N/A) when: The Kubernetes cluster does not support Pod Security Standards (versions before 1.25).
-
Cross-reference: The
no-privileged-containerscheck verifies individual container security contexts, while this check enforces standards at the namespace level. -
Detail on fail: Quote the namespace. Example:
"Namespace 'production' does not have Pod Security Standards labels. Privileged pods can be deployed."or"PSS labels present on 'production' but set to 'baseline' instead of 'restricted'" -
Remediation: Enable Pod Security Standards on your namespace:
kubectl label namespace production \ pod-security.kubernetes.io/enforce=restricted \ pod-security.kubernetes.io/enforce-version=latest \ pod-security.kubernetes.io/audit=restricted \ pod-security.kubernetes.io/warn=restricted
External references
- nist:rev5 · AC-3 — Access Enforcement
- external · CIS-Kubernetes-5.2.1 — CIS Kubernetes Benchmark §5.2.1 — Do not admit privileged containers
- external · CIS-Kubernetes-5.2.6 — CIS Kubernetes Benchmark §5.2.6 — Do not admit root containers
Taxons
History
- 2026-04-18·v1.0.0·Initial import from infrastructure-hardening·automated