Skip to main content

More Info:

Do not generally permit containers to be run as the root user.

Risk Level

Critical

Address

Security

Compliance 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

Manual Steps

  1. 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.).
  2. 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).
  3. 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 has spec.runAsUser.rule: MustRunAsNonRoot or MustRunAs with UID ranges that exclude 0, and which ServiceAccounts / namespaces are bound to them (via RBAC Role/ClusterRole and bindings).
  4. 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.
  5. Based on the above, decide one of the following per namespace:
    • Tighten or create a PSP with spec.runAsUser.rule: MustRunAsNonRoot or MustRunAs with UID ranges not including 0, 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 restricted level, OPA Gatekeeper, Kyverno), ensuring their rules/constraints prevent runAsUser: 0 or allowPrivilegeEscalation: true and root images where appropriate.
  6. 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 Running pod should appear):
Review each namespace’s policies and workloads.

1. Check for PodSecurityPolicy (if enabled)

What to look for in each PSP:
  • .spec.runAsUser.rule missing or set to RunAsAny
    → Indicates pods using this PSP may run as root.
  • If .spec.runAsUser.rule: MustRunAs, check .spec.runAsUser.ranges
    → If any range includes 0 (for example min: 0 or 0-65535), root is allowed.
  • If .spec.runAsUser.rule: MustRunAsNonRoot
    → This PSP is aligned with the recommendation.
If you have PSPs that allow root, identify which namespaces/service accounts use them:
Bindings that allow use of a PSP which permits root are potential problems, especially in non-admin namespaces.

2. Check Pod-level securityContext (current workloads)

Problem indicators:
  • runAsUser is 0 → the pod explicitly requests root.
  • runAsNonRoot is 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)

Problem indicators per container:
  • runAsUser is 0 → explicit root container.
  • Both pod-level and container-level runAsNonRoot unset/false and no admission control enforcing non-root → container likely allowed to run as root.

4. Inspect deployments/statefulsets for templates that allow root

Within each pod template:
  • securityContext.runAsUser: 0 at pod or container level → potentially problematic.
  • securityContext.runAsNonRoot: true and no runAsUser: 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:
Any listed pod is explicitly configured to run as root. Those namespaces and workloads need human review to decide whether root is justified (e.g., node agents, CNI components) or should be changed.

Additional Reading: