No containers run with privileged flag or securityContext.privileged: true

A privileged container (securityContext.privileged: true) has direct access to the host kernel, all devices, and the host network namespace — it is functionally equivalent to running as root on the node itself (CWE-250). Any exploit in a privileged container breaks out of containment immediately. NIST 800-53 CM-7 requires minimal functionality. CIS Kubernetes 5.2.1 prohibits privileged containers. Even when a container has a legitimate need for elevated access (e.g., packet capture), specific capabilities (NET_ADMIN, NET_RAW) are always preferable to blanket privilege.

Remove securityContext.privileged: true from all container definitions. If the workload genuinely needs elevated access, grant the minimum required Linux capability instead. In your Deployment manifest:

containers:
  - name: app
    securityContext:
      runAsNonRoot: true
      runAsUser: 1001
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE  # Only if binding ports < 1024
      readOnlyRootFilesystem: true

For monitoring sidecars that historically required privilege, evaluate eBPF-based alternatives (e.g., Falco, Cilium) that operate without privileged mode.

• ID: infrastructure-hardening.access-control-rbac.no-privileged-containers

• Severity: medium

• What to look for: Count every container definition across all Kubernetes Pod, Deployment, StatefulSet, and DaemonSet manifests — including init containers and sidecar containers. For each container, check whether securityContext.privileged is set to true. Count the total containers and how many run privileged.

• Pass criteria: Fewer than 1 container across any production manifest has securityContext.privileged: true or --privileged runtime flags — meaning 0% privileged. Every container — including init containers and sidecars — runs in unprivileged mode with at least capabilities.drop: [ALL]. Report the count: "X of Y containers verified unprivileged."

• Fail criteria: Any production container has securityContext.privileged: true, or a privileged flag is set in the container runtime.

• Skip (N/A) when: The project does not use Kubernetes containers, or a privileged container is explicitly justified (e.g., monitoring sidecar with documented justification).

• Detail on fail: Quote the manifest and container name. Example: "Deployment 'app' has securityContext.privileged: true on container 'main'. No privilege justification found."

• Remediation: Use unprivileged containers. Privileged mode grants host-level access, breaking containment. If your application needs elevated capabilities, grant specific capabilities instead:

  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    capabilities:
      add:
        - NET_BIND_SERVICE  # Only if needed for ports < 1024
      drop:
        - ALL  # Drop all others
    readOnlyRootFilesystem: true