More Info:
Do not generally permit containers to be run as the root user.Risk Level
CriticalAddress
SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS GKE
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
On any machine with kubectl access, list all namespaces and identify those that should be protected from root containers (typically all except system namespaces you explicitly exempt):
Decide which namespaces must disallow root containers (e.g.
prod,staging,default, etc.). -
For each selected namespace, review existing Pod Security admission labels (if using built‑in Pod Security Standards) to understand current posture:
Note any
pod-security.kubernetes.io/*labels that might already restrict root (e.g.restricted). -
If your cluster still uses PodSecurityPolicy (PSP), list and inspect all PSPs to see whether they restrict root via
spec.runAsUser.rule:Confirm whether any PSP hasspec.runAsUser.rule: MustRunAsNonRootorMustRunAswith UID ranges that exclude0, and which ServiceAccounts / namespaces are bound to them (via RBACRole/ClusterRoleand bindings). -
For each protected namespace, identify ServiceAccounts used by workloads and see what PSP (if any) they can use:
From these bindings, determine which PSPs apply to each ServiceAccount and whether they enforce non‑root execution as required.
-
Based on the above, decide one of the following per namespace:
- Tighten or create a PSP with
spec.runAsUser.rule: MustRunAsNonRootorMustRunAswith UID ranges not including0, and bind it only to the ServiceAccounts in that namespace that should never run root. - If PSP is not used or is deprecated in your environment, implement an equivalent policy via your chosen admission controller (e.g. Pod Security Standards
restrictedlevel, OPA Gatekeeper, Kyverno), ensuring their rules/constraints preventrunAsUser: 0orallowPrivilegeEscalation: trueand root images where appropriate.
- Tighten or create a PSP with
-
After changes, deploy or update a representative workload in each affected namespace and verify admission behavior:
- Try to create a pod that explicitly runs as root (this should now be rejected):
- Confirm it is denied (no
Runningpod should appear):
- Try to create a pod that explicitly runs as root (this should now be rejected):
Using kubectl
Using kubectl
1. Check for PodSecurityPolicy (if enabled)
.spec.runAsUser.rulemissing or set toRunAsAny
→ Indicates pods using this PSP may run as root.- If
.spec.runAsUser.rule: MustRunAs, check.spec.runAsUser.ranges
→ If any range includes0(for examplemin: 0or0-65535), root is allowed. - If
.spec.runAsUser.rule: MustRunAsNonRoot
→ This PSP is aligned with the recommendation.
use of a PSP which permits root are potential problems, especially in non-admin namespaces.2. Check Pod-level securityContext (current workloads)
runAsUseris0→ the pod explicitly requests root.runAsNonRootis empty/false and nothing else prevents root → pod may run as root via container image defaults or container-level settings.
3. Check container-level securityContext (current workloads)
runAsUseris0→ explicit root container.- Both pod-level and container-level
runAsNonRootunset/false and no admission control enforcing non-root → container likely allowed to run as root.
4. Inspect deployments/statefulsets for templates that allow root
securityContext.runAsUser: 0at pod or container level → potentially problematic.securityContext.runAsNonRoot: trueand norunAsUser: 0→ aligned with recommendation.- No securityContext at all → admission policy decides; if none, workloads may run as root.
5. For each namespace, summarize root usage
For a quick per-namespace view:Automation
Automation

