Why is this an issue?

The Docker daemon provides an API to control its functionality through a UNIX domain socket at /var/run/docker.sock. Mounting this socket into a container allows the container to control the Docker daemon of the host system, including the ability to start new privileged containers, access other running containers, and mount the host filesystem — resulting in full control over the entire system.

What is the potential impact?

A compromised or rogue container with access to the Docker socket can control the host’s Docker daemon, giving an attacker full access to the host system. This can endanger the integrity of the entire Kubernetes cluster.

How to fix it

Never mount the Docker socket (/var/run/docker.sock) as a volume in a container. If container management is required from within a pod, use the Kubernetes API instead.

Code examples

The following code mounts the Docker socket into a container, giving it full control over the host’s Docker daemon.

Noncompliant code example

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /var/run/docker.sock # Noncompliant
      type: Socket

Compliant solution

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container

Resources

Documentation

Standards