Minimize The Admission Of Root Containers

1. List all namespaces and identify those that should host only non-root workloads
   • Run on: any machine with kubectl access
   • Command:
     kubectl get ns
     
   • Decide which namespaces must be restricted (for example: prod, staging, or all except explicitly “infra/ops” namespaces that may need privileged containers).
2. Review existing PodSecurity admission / security policies per target namespace
   • Run on: any machine with kubectl access
   • Commands (use what’s relevant to your cluster):
     • For built-in Pod Security Admission labels:
       kubectl get ns --show-labels
       
       Look for labels like pod-security.kubernetes.io/enforce=restricted (which already forbids root in most cases).
     • For PodSecurityPolicy (legacy clusters):
       kubectl get psp -o yaml
       
       Review runAsUser fields; confirm rule: MustRunAsNonRoot or rule: MustRunAs with all ranges having min > 0.
     • For common policy engines (example: Gatekeeper):
       kubectl get constraints --all-namespaces
       
       Review any constraints controlling runAsUser / runAsNonRoot.
3. Inspect current pod specs to find workloads that run as root or allow root
   • Run on: any machine with kubectl access
   • Command (namespaced, repeat for each important namespace):
     NAMESPACE=default
     kubectl get pods -n "$NAMESPACE" -o json \
       | jq -r '.items[]
         | .metadata.name as $p
         | (.spec.securityContext.runAsUser // "namespace-default") as $podUID
         | (.spec.securityContext.runAsNonRoot // "namespace-default") as $podNonRoot
         | .spec.containers[]
         | {
             pod: $p,
             container: .name,
             cRunAsUser: (.securityContext.runAsUser // $podUID),
             cRunAsNonRoot: (.securityContext.runAsNonRoot // $podNonRoot)
           }' \
       | jq -r 'select(.cRunAsUser == 0 or .cRunAsNonRoot == false or .cRunAsNonRoot == "namespace-default")'
     
   • Use this output to identify pods that are explicitly root or unconstrained (no non-root requirement and no non-root namespace default).
4. Design and apply namespace-level policy requiring non-root UIDs
   • Decide whether you can adopt a strict policy (no root anywhere in that namespace) or need exceptions.
   • For Pod Security Admission (recommended where available), raise the namespace to at least restricted (which enforces non-root by default) or confirm it is already at that level:
     NAMESPACE=default
     kubectl label ns "$NAMESPACE" \
       pod-security.kubernetes.io/enforce=restricted \
       pod-security.kubernetes.io/audit=restricted \
       pod-security.kubernetes.io/warn=restricted \
       --overwrite
     
   • For policy engines (e.g., Gatekeeper/Kyverno), create or update a policy in each target namespace so that containers must set runAsNonRoot: true or runAsUser with UID > 0, and exclude 0 from any allowed ranges (done via their CRDs and admission rules).
5. Refactor or exempt workloads that cannot yet run as non-root
   • Using the pods discovered in step 3, update their deployment/statefulset/daemonset manifests to set non-root contexts:
     • Example change in the pod template:
       securityContext:
         runAsNonRoot: true
         runAsUser: 1000
       
       And, if needed, per-container overrides under spec.template.spec.containers[].securityContext.
   • If some workloads absolutely require root, formally document them and either:
     • move them into a separate, tightly controlled namespace without the non-root policy, or
     • configure scoped policy exceptions (policy engine exemptions or narrower admission rules) only for those workloads.
6. Verify enforcement and absence of new root-running pods
   • Run on: any machine with kubectl access
   • Attempt to create a pod that runs as root in a restricted namespace; it should be rejected:
     cat <<'EOF' >/tmp/root-pod-test.yaml
     apiVersion: v1
     kind: Pod
     metadata:
       name: root-pod-test
     spec:
       securityContext:
         runAsUser: 0
       containers:
       - name: test
         image: busybox
         command: ["sh", "-c", "id -u && sleep 3600"]
     EOF
     
     NAMESPACE=default
     kubectl apply -n "$NAMESPACE" -f /tmp/root-pod-test.yaml
     
   • Confirm that admission rejects this pod (error message from PSA or your policy engine).
   • Re-run the inspection from step 3 to ensure no newly created pods are running as root or without a non-root requirement.

​

Using kubectl

​

1. List all namespaces to scope your review

kubectl get ns

​

2. Inspect PodSecurity admission / PodSecurityPolicy-like controls per namespace

2.1. Check for Pod Security standards labels (if PodSecurity admission is enabled)

kubectl get ns --show-labels

• pod-security.kubernetes.io/enforce=baseline or restricted
• pod-security.kubernetes.io/enforce-version=v1.30 (version may differ)

• Namespaces with no pod-security.kubernetes.io/enforce label.
• Namespaces where pod-security.kubernetes.io/enforce=privileged.
• Namespaces intended to be restricted that have no PodSecurity labels at all.

2.2. If using Gatekeeper/Kyverno or similar, list policies related to runAsNonRoot

kubectl get k8spsps,configs,constraints.constraints.gatekeeper.sh,crd -A 2>/dev/null | grep -i runasnonroot || true
kubectl get constraints.constraints.gatekeeper.sh -A 2>/dev/null | grep -Ei 'runas(non)?root|securitycontext' || true

kubectl get cpol,pol -A 2>/dev/null | grep -Ei 'runas(non)?root|securitycontext' || true

• No constraint/policy objects that mention runAsNonRoot, runAsUser, or securityContext.
• Policies exist but are audit or warn only (no enforce mode) where enforcement is desired.

​

3. Examine existing policies (where present) for MustRunAs / MustRunAsNonRoot semantics

kubectl get <constraint-kind> -A -o yaml | less

• runAsNonRoot: true
• runAsUser strategy using MustRunAs with rule: MustRunAs and ranges excluding UID 0
• Or explicit deny rules if runAsUser: 0 is set.

• No mention of runAsNonRoot or runAsUser in the policy.
• MustRunAs ranges include 0 (for example min: 0).
• Policies scoped only to a small subset of namespaces, leaving others unprotected.

​

4. Spot-check workloads’ securityContext to understand current behavior

kubectl get pods -n myns -o yaml | grep -E "name:|runAsUser:|runAsNonRoot:" -n

kubectl get pods -n myns -o jsonpath='{range .items[*]}{@.metadata.name}{"\t"}{@.spec.securityContext.runAsNonRoot}{"\t"}{@.spec.securityContext.runAsUser}{"\n"}{end}'

• Pods with runAsUser: 0.
• Pods with no runAsUser and no runAsNonRoot, combined with images that default to root (this needs human review of the images).
• Absence of any namespace-level policy while such pods exist.

​

5. Verify absence or presence of PodSecurityPolicy (older clusters only)

kubectl get podsecuritypolicies.policy 2>/dev/null

kubectl get podsecuritypolicies.policy -o yaml | less

• rule: MustRunAsNonRoot or
• rule: MustRunAs with ranges where all min > 0.

• runAsUser.rule is RunAsAny.
• MustRunAs ranges include UID 0.
• No PSP bound via RBAC to the service accounts in the reviewed namespaces.

#!/usr/bin/env bash
# Report pods and controllers that can run as root (UID 0) or lack non-root restrictions.
# Run on any machine with kubectl access and a current context.

set -euo pipefail

echo "=== Cluster-wide Pod Security Settings Report (focus: root containers) ==="
echo "Timestamp: $(date)"
echo

###############################################################################
# 1. Namespaces WITHOUT any PodSecurityPolicy/PodSecurityAdmission-equivalent
#    namespace-level policy label that enforces non-root.
#    NOTE: You must adapt this section to your cluster's admission controller:
#      - For Pod Security Admission (built-in): uses pod-security.kubernetes.io/*
#      - For OPA Gatekeeper/Kyverno/etc.: list and review their constraints separately.
###############################################################################

echo "==[1] Namespaces and Pod Security labels (for built-in Pod Security Admission) =="
kubectl get ns --show-labels | sed 's/,/\n    /g'
echo
cat <<'EOF'
Review:
- For clusters using built-in Pod Security Admission:
  * Namespaces that do NOT have labels like:
      pod-security.kubernetes.io/enforce=baseline
      pod-security.kubernetes.io/enforce=restricted
    or equivalent, are likely NOT protected by a baseline/restricted policy and
    may allow root containers. These are candidates for new policies.
- If you use another admission mechanism (Gatekeeper, Kyverno, etc.), review its
  constraints separately; this script only surfaces PSA labels.
EOF
echo

###############################################################################
# 2. Pods with effective root user (runAsUser=0 or defaulting to root) or that
#    do not explicitly forbid root (runAsNonRoot != true).
#    This is for REVIEW ONLY; it does NOT mean "always unsafe", but these are
#    the prime candidates to bring under policy.
###############################################################################

echo "==[2] Pods that can run as root or do not explicitly require non-root =="

# Show:
# - Namespace, Pod, Container
# - Pod-level securityContext.runAsUser / runAsNonRoot
# - Container-level securityContext.runAsUser / runAsNonRoot
# - ServiceAccount
kubectl get pods --all-namespaces -o json \
| jq -r '
  .items[]
  | . as $pod
  | ($pod.spec.containers[]? // []), ($pod.spec.initContainers[]? // []) 
  | . as $c
  | {
      ns: $pod.metadata.namespace,
      pod: $pod.metadata.name,
      kind: (if ($pod.spec.initContainers // []) | index($c) then "initContainer" else "container" end),
      cname: .name,
      sa: ($pod.spec.serviceAccountName // "default"),
      podRunAsUser: ($pod.spec.securityContext.runAsUser // "null"),
      podRunAsNonRoot: ($pod.spec.securityContext.runAsNonRoot // "null"),
      cRunAsUser: (.securityContext.runAsUser // "null"),
      cRunAsNonRoot: (.securityContext.runAsNonRoot // "null")
    }
  | . as $r
  | $r
  | select(
      # Flag if:
      # 1) Explicitly configured to run as UID 0 at pod or container level
      ($r.podRunAsUser == 0 or $r.cRunAsUser == 0)
      or
      # 2) Neither pod nor container explicitly has runAsNonRoot=true,
      #    meaning root is not forbidden and may be used.
      (
        ($r.podRunAsNonRoot != true)
        and ($r.cRunAsNonRoot != true)
      )
    )
  | [
      .ns,
      .pod,
      .kind,
      .cname,
      "sa=" + .sa,
      "podRunAsUser=" + (.podRunAsUser|tostring),
      "podRunAsNonRoot=" + (.podRunAsNonRoot|tostring),
      "cRunAsUser=" + (.cRunAsUser|tostring),
      "cRunAsNonRoot=" + (.cRunAsNonRoot|tostring)
    ]
  | @tsv
' | column -t

cat <<'EOF'

Interpretation of section [2] output (POTENTIAL PROBLEMS):

Each line shows:
  NAMESPACE  POD  [container|initContainer]  CONTAINER_NAME  sa=SERVICEACCOUNT \
  podRunAsUser=...  podRunAsNonRoot=...  cRunAsUser=...  cRunAsNonRoot=...

Pay special attention to:
- podRunAsUser=0 or cRunAsUser=0
  -> These are explicitly configured to run as root (UID 0). This is a direct
     violation of "MustRunAsNonRoot" guidance unless there is a strong,
     documented exception.

- podRunAsNonRoot=null AND cRunAsNonRoot=null with podRunAsUser=null AND cRunAsUser=null
  -> Neither pod nor containers demand non-root, and no explicit UID is set.
     In many images the default user is root, so these are likely root-capable.
     These are candidates to:
       * Set runAsNonRoot: true (pod and/or container level), or
       * Set runAsUser to a non-zero UID.

The benchmark remediation requires you to create a policy for each namespace
ensuring that:
  - runAsUser is configured via MustRunAsNonRoot, OR
  - MustRunAs is used with a UID range that excludes 0.

This script only surfaces workloads that currently:
  - Can run as root, or
  - Do not clearly require non-root.
You must then:
  - Decide where non-root is feasible,
  - Adjust images/manifests accordingly,
  - And enforce via your chosen admission policy mechanism.
EOF

• Re-run the script on any machine with kubectl access.
• A healthy state is when:
  • Namespaces have appropriate policy labels (or equivalent policy via another controller).
  • Section [2] returns:
    • No lines with podRunAsUser=0 or cRunAsUser=0.
    • As few as possible lines where runAsNonRoot is not true; any remaining should be documented exceptions.