More Info:
Pod Security Admission should enforce at least the Baseline profile on every namespace containing user workloads to block privileged and unsafe pod configurations. Namespaces without an enforce label are unprotected.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
On any machine with kubectl access, list all namespaces and see which already have an enforce label (and what level it is set to):
Focus on the
pod-security.kubernetes.io/enforcelabel; note any namespaces withprivileged,baseline,restricted, or no value. -
Identify namespaces that currently enforce a profile weaker than Baseline or have no enforce label:
From this list, mark:
- Namespaces with empty (no label) or missing value.
- Namespaces with
privileged(weaker than Baseline). - Exclude known system/control-plane namespaces if your policy allows different treatment there (e.g.
kube-system,kube-public,kube-node-lease, provider-specific system namespaces).
-
For each remaining (non-system) namespace, determine whether it hosts user workloads:
Alternatively, check selectively for any candidate namespace from step 2:Treat any namespace running business applications, batch jobs, or user-facing services as a “user workload” namespace.
-
For each namespace that both (a) contains user workloads and (b) lacks an adequate enforce label (none/privileged), decide the target profile:
- Minimum:
baseline(per remediation). - Prefer
restrictedif workloads are known to be hardened and compatible.
Before changing, confirm with application owners whether their workloads depend on privileged containers, hostPath volumes, host networking, or other disallowed settings under Baseline/Restricted.
- Minimum:
-
Apply or adjust the enforce label using kubectl on each chosen namespace (any machine with kubectl access):
- To enforce Baseline (minimum required):
- To enforce a stricter Restricted profile (if suitable):
- To enforce Baseline (minimum required):
-
Verify that all user-workload namespaces now enforce at least Baseline:
Optionally, rerun the original audit to confirm the delta between Baseline-enforced namespaces and all namespaces, then manually confirm that any remaining unlabelled namespaces indeed do not contain user workloads or are intentionally exempt:
Using kubectl
Using kubectl
- Problem indication: Any namespace that runs or may run user workloads where
ENFORCEis empty/<none>or weaker than your policy (e.g.,privilegedwhen you requirebaselineorrestricted).
- Problem indication: Any listed namespace that hosts user workloads (applications, jobs, CI workloads, etc.) needs human review; if they should be protected, they are currently unprotected by Pod Security Admission.
- Problem indication: Any lines starting with
>are namespaces that do not havepod-security.kubernetes.io/enforce=baseline. For each of those, a human must decide:- Does this namespace contain or will it contain user workloads?
- If yes, should it enforce
baselineor a stricter profile (restricted), or be exempt for a clear reason?
- Problem indication: If this shows user workloads and the namespace lacks an appropriate
pod-security.kubernetes.io/enforcelabel (or is weaker than your policy), that namespace is in scope for remediation.
Automation
Automation

