Why is this an issue?

Running containers in privileged mode weakens the isolation between the container and the host, granting processes inside the container essentially the same permissions as the root user on the host. This elevated access undermines the security boundary that containers are meant to provide.

What is the potential impact?

Container escape

If an attacker compromises a process running inside a privileged container, they can gain root-level access to the host system.

Infrastructure compromise

From there, they can pivot to other systems accessible from the host, compromising the broader infrastructure.

Cluster-wide escalation

In a Kubernetes environment, a host compromise has an amplified blast radius. An attacker with root access to a node can access kubelet credentials and the service account tokens of every pod scheduled on that node. Depending on the cluster’s RBAC configuration, this can allow them to escalate to cluster-admin privileges via the Kubernetes API server, compromising the entire cluster.

How to fix it

Code examples

The following code runs a container with privileged: true, granting it root-level access to the host system.

Noncompliant code example

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
      securityContext:
        privileged: true # Noncompliant

Compliant solution

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
      securityContext:
        privileged: false

Resources

Standards