Access to the Docker socket is root on the host: what mounting it into a container really grants

What it is

Docker's security documentation says the daemon requires root privileges unless Rootless mode is used, and that only trusted users should be allowed to control it. The reason given: Docker lets you share a directory between host and container without limiting the container's access rights, so a container can be started with the host's / mounted and alter the host file system freely.

The Unix socket /var/run/docker.sock is the usual control channel. Anyone who can write to it controls the daemon.

Why it matters

Several common setups hand out that control without saying so:

• Mounting the socket into a container so that it can manage other containers (CI runners, dashboards, reverse proxies that read labels, agent sandboxes that spawn sibling containers). A compromise of that container becomes a compromise of the host.
• The docker group: membership is effectively root on the machine.
• The TCP API without TLS client authentication, which grants the same to anyone on the network.

For agents, the socket is attractive because it makes "run this in a container" easy; it also means the sandbox can escape itself with one API call.

How to apply

• Inventory which containers mount the socket: docker inspect on all containers and look for the socket path in mounts.
• Where a tool only reads container metadata, put a filtering proxy in front of the socket that allows the read-only endpoints it needs, and mount that instead.
• Run agent sandboxes that must start containers with Rootless mode, a separate daemon, or a VM boundary rather than the host daemon.
• Keep the docker group as small as the sudoers list and review both together.
• Never expose the API over TCP without mutual TLS; prefer SSH access to the socket.

Pitfalls

• Read-only bind mount of the socket (:ro): it prevents replacing the socket file, not sending API requests through it.
• Assuming user namespaces or a non-root user inside the container help; the daemon acting on the request is still root.