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

- **Pattern:** `ab-001639` (`infrastructure-hardening.access-control-rbac.no-privileged-containers`)
- **Severity:** medium
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001639
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001639)

## Why it matters

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.

## Severity rationale

Medium because privileged mode breaks container isolation entirely, but exploitation still requires a separate code execution path within the container first.

## Remediation

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:

```yaml
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.

## Detection

- **ID:** `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:

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

## External references

- cwe CWE-250
- nist CM-7
- external CIS-Kubernetes-5.2.1 — https://www.cisecurity.org/benchmark/kubernetes

Taxons: operational-readiness

HTML version: https://auditbuffet.com/patterns/ab-001639