Docker socket

Why mounting it is risky

Many tools ask you to mount the socket into a container. That gives the container the ability to start new containers, including one that mounts the host filesystem. OWASP also notes that mounting the socket read-only does not make the Docker API read-only.

How to handle it safely

Keep the socket out of containers where possible, restrict the docker group to trusted administrators, never expose the daemon over TCP without TLS and consider rootless mode. The details are in our Docker host security guide.

How to audit who can reach the socket

The dockerd reference says that by default the daemon creates /var/run/docker.sock and only root or members of the docker group can use it. Auditing access therefore means answering three questions, each with one command:

ls -l /var/run/docker.sock
getent group docker
docker ps --filter volume=/var/run/docker.sock --format "table {{.ID}}\t{{.Names}}"

The first shows the owner and group of the socket file. If the group is anything other than docker or the permissions are wider than expected, find out why. The second lists every member of the group, which should be people you would trust with root, since Docker states that the group grants root-level privileges. Using getent rather than reading /etc/group also includes accounts from directory services. The third uses the documented volume filter of docker ps to list running containers that have the socket mounted.

That command misses stopped containers and services that are not running yet, so also search your configuration for definitions that would mount it:

grep -rn "docker.sock" /opt /srv --include="*.yml" --include="*.yaml"

Adjust the paths to where your compose files live. Record every hit with the reason it needs the socket, and remove the ones nobody can justify. See least privilege for the principle behind this review.

Socket proxies, rootless mode and remote access

When a tool genuinely needs the API, narrow what it can do. The Tecnativa docker-socket-proxy project puts an HAProxy-based filter in front of the socket and answers forbidden requests with HTTP 403. Per its README, only the EVENTS, PING and VERSION sections are allowed by default, and the POST setting is off by default, which leaves the API read-only. You enable only the sections the tool needs, with environment variables such as CONTAINERS=1. The README also warns never to expose the proxy's port to a public network and to keep it on a Docker network shared only with the tool that uses it. Note that the proxy container itself mounts the real socket, so it narrows access rather than removing the risk.

A different approach is to shrink the daemon's privileges. In rootless mode the daemon runs as an ordinary user, and the socket then sits in that user's runtime directory instead, for example unix:///run/user/1000/docker.sock in Docker's example. Docker describes the mode as a way to mitigate potential vulnerabilities in the daemon and the container runtime.

For remote administration, prefer an SSH connection to a TCP listener. Docker's protect access documentation shows a context created with a host=ssh:// address, and notes that the SSH user must have permission to use the socket on the remote machine, so that account is still root-equivalent. Guard its keys accordingly using the SSH hardening guide.

Related terms: Least privilege, UID 0, Firewall, UFW, Docker socket proxy.