The Docker socket — the most dangerous API on the host · Docker & Containers

/var/run/docker.sock is the daemon’s control plane. It speaks HTTP over a unix socket, it runs as root, and — this is the part that matters — it does not authenticate or authorise anything. There is no user model in the Docker API. If your process can connect() to that socket, every API call succeeds. There is no read-only mode, no scope, no token, no per-endpoint permission.

A container with that socket bind-mounted into it therefore has, in practice, the same power as root on the host.

The escalation path, in prose

It is worth walking through exactly how, because “equivalent to root” sounds like hyperbole until you see that it takes no vulnerability at all. Every step below is a documented, supported Docker API call being used exactly as designed.

An attacker with code execution inside a container that has the socket mounted:

Connects to the socket. No credential is needed. The API is plain HTTP over the unix socket; a single POST is all that is required. Nothing in Docker distinguishes this connection from the operator’s docker CLI.
Asks the daemon to create a second container. The attacker controls the entire container spec: image, command, mounts, capabilities, namespaces. Note where this happens — in the daemon, on the host, outside the first container’s confinement. The first container’s --cap-drop=ALL, seccomp profile, AppArmor profile, read-only root and non-root user are all irrelevant, because none of them apply to the container the daemon is about to create.
Specifies a spec that reaches the host. The obvious choice is the host root filesystem bind-mounted into the new container. The equally effective choices are host PID namespace, host network namespace, or full privilege — the API accepts all of them, and the daemon has no policy that would refuse.
Starts it, and reads or writes the host. With the host root mounted, that means writing an authorised key, a systemd unit, or a cron.d entry. With the host PID namespace, it means entering the namespaces of PID 1. Either way the process is running as host root, because the daemon runs as host root and creates its children accordingly.

No kernel bug. No container escape. No Docker defect. The container asked the daemon politely and the daemon, which has no concept of “who is asking”, complied.

The three defences that do not work here

Each of these is deployed regularly in the belief that it contains the socket. None of them do.

Mounting the socket :ro. Connecting to a unix socket is not a filesystem write. A read-only bind mount of docker.sock gives the container the complete, unrestricted, read-write Docker API. This is the single most common mistake in the ecosystem.
Hardening the container that holds the socket. --cap-drop=ALL --read-only --security-opt no-new-privileges=true constrains what that container may do. The escalation happens in a different container, created by the daemon with whatever spec the attacker chose. Your hardening does not travel.
Running the app as a non-root user. This one can help, but only by accident and only sometimes. The socket is typically srw-rw---- root docker, so a container process needs UID 0 or a GID matching the socket’s group to connect. Plenty of Compose files then add group_add or run as root anyway, and the protection evaporates. Never rely on it as the control.

The “legitimate” use cases

Some workloads genuinely need to talk to the daemon:

CI/CD runners that build images or start service containers.
Reverse proxies that discover containers by label (Traefik, Caddy’s Docker adapter).
Monitoring agents that read container state.
Log shippers that resolve container IDs to names.
Deployment agents (Watchtower and similar) that pull and recreate.

These are real. “Never mount the socket” as a blanket rule breaks them, and a rule that breaks the workflow gets bypassed rather than followed. The useful framing is that every one of these needs strictly less than the full API, and the job is to give them only that.

Note the split: the proxies, monitors and log shippers need GET only. The CI runners and deployment agents need to create containers, which means they are host-equivalent by definition and must be treated as trusted infrastructure — isolated hosts, short-lived VMs, or a nested rootless daemon — not as sandboxed workloads that happen to have a mount.

Alternative 1: a filtering socket proxy

The proxy sits between the workload and the socket and rejects requests by HTTP method and API path. The widely used implementation is tecnativa/docker-socket-proxy, an HAProxy with an ACL set driven by environment variables.

services:
  socket-proxy:
    image: tecnativa/docker-socket-proxy:0.3.0
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      # POST defaults to 0. With it off, only GET and HEAD reach the
      # daemon, which makes every enabled section read-only.
      POST: 0
      CONTAINERS: 1
      # everything else stays at its revoked default
      IMAGES: 0
      NETWORKS: 0
      VOLUMES: 0
      EXEC: 0
      SECRETS: 0
      AUTH: 0
    networks:
      - proxy-net
    # No port published to the host. Only the app network reaches it.

  my-app:
    image: myorg/myapp:1.0.0
    environment:
      DOCKER_HOST: tcp://socket-proxy:2375
    networks:
      - proxy-net
    depends_on:
      - socket-proxy

networks:
  proxy-net:
    internal: true

Two details carry the whole configuration:

POST: 0 is what makes this safe, not CONTAINERS: 1. CONTAINERS grants the /containers/ section of the API, which includes POST /containers/create. It is the method filter that reduces the section to listing and inspecting. Turn POST on and CONTAINERS: 1 becomes “create any container you like”, which is where you started.
Do not publish the proxy’s port to the host. The example that ships with the project maps 127.0.0.1:2375:2375 for local testing. In production the proxy should be reachable only on an internal: true Docker network. A 2375 on 0.0.0.0 is an unauthenticated root API on the network, which is materially worse than the mount you were trying to remove.

EXEC: 1 deserves its own warning: it permits POST /containers/{id}/exec, which runs a command in an existing container. Combined with any container on the host that is privileged or has the host root mounted, that is a complete escalation with POST restricted to one endpoint.

Alternative 2: don’t put the API on the host at all

Configuration changessh transport— Docker's own recommended way to reach a remote daemon. Authentication and authorisation are sshd's, which is a real user model.

docker context create \
  --docker host=ssh://docker-user@host1.example.com \
  --description="Remote engine" \
  my-remote-engine

docker context use my-remote-engine
docker info

The remote user still needs socket access on the far side, so this does not reduce that user’s power — it moves the trust boundary to SSH, where you have keys, authorized_keys restrictions, Match blocks, revocation and an audit trail. That is a trust boundary you can actually administer.

Alternative 3: TLS on TCP

Configuration changedaemon with mutual TLS— Client certificate authentication on port 2376. Note --tlsverify: without it, TLS provides encryption and no authentication at all.

dockerd \
  --tlsverify \
  --tlscacert=/etc/docker/ca.pem \
  --tlscert=/etc/docker/server-cert.pem \
  --tlskey=/etc/docker/server-key.pem \
  -H=0.0.0.0:2376

Port 2376 is TLS; 2375 is plaintext and must never be reachable by anything. Anyone holding a valid client certificate has root on that host, so treat certificate issuance with the same process as handing out root SSH keys, and set an expiry short enough that revocation is not the only mechanism you have.

Alternative 4: rootless

Under rootless Docker the socket lives at $XDG_RUNTIME_DIR/docker.sock (typically /run/user/1000/docker.sock) and the daemon runs as that unprivileged user. A container that reaches this socket can still create containers — but they are created by an unprivileged daemon, so “host root” is no longer at the end of the chain. It is the strongest of the four alternatives for the CI-runner case specifically.

Auditing

Read-only / Safefind every container with a daemon socket— Checks both the Docker and containerd sockets across every running container.

$ docker ps -q | xargs -r -I{} docker inspect --format '{{.Name}}{{range .Mounts}} {{.Source}}{{end}}' {} | grep -E 'docker\.sock|containerd\.sock'

/ci-runner /var/run/docker.sock
/traefik /var/run/docker.sock
/watchtower /var/run/docker.sock

Illustrative output

Three findings with three different answers: traefik needs GET only and belongs behind a proxy with POST: 0; watchtower needs to create containers and is therefore host-equivalent infrastructure that should not sit next to application workloads; ci-runner should be on its own disposable host.

Read-only / Safewho else can reach the socket— Socket mode and group, then the members of that group. Everyone listed has root on this host.

ls -l /var/run/docker.sock
SOCK_GRP=$(stat -c '%G' /var/run/docker.sock)
getent group "$SOCK_GRP"

Membership of the docker group is not “permission to run containers”. It is root, without sudo logging, without a password prompt, and without appearing in /var/log/auth.log. Audit that group with the same seriousness as sudoers.

Why the API has no authorisation layer, and what to do about it

The Docker API was designed as a local administrative interface, in the same category as /dev/kvm or the systemd private socket: access control is the file mode on the socket, and everything past that point is trusted. That decision is baked deep enough that adding per-endpoint permissions to the daemon is not on the table.

You can watch it work with nothing but curl, which is also the cleanest way to prove a finding without running anything destructive:

curl -s --unix-socket /var/run/docker.sock http://localhost/version | head -c 200

A 200 response with a JSON version document means the caller has the complete API. There is no second step, no login, no token exchange. That single GET is the whole authentication story.

Docker does ship one extension point: authorization plugins (--authorization-plugin), which get a callback before and after every API request and can deny it. They are the only supported way to put policy inside the daemon rather than in front of it. They are also rare in the field, need a plugin you trust in the request path of every API call, and fail closed — which is correct and also means a plugin crash stops all container operations on the host. Evaluate them for regulated environments; reach for the proxy or the SSH transport first everywhere else.

Note that the API is versioned in the path (/v1.51/containers/json) and that omitting the version, as above, means “latest the daemon supports”. Nothing about the version negotiation is a security boundary.

What happens if you remove the socket mount from a running Traefik or Watchtower?

You cannot change a mount on a running container, so this is a recreate, and the failure mode differs by tool:

Traefik stops discovering containers. Existing routes keep serving from its in-memory configuration until it reloads, then every route 404s. The symptom looks like a DNS or certificate problem and is not; check the provider logs for Cannot connect to the Docker daemon.
Watchtower logs a connection error on its next poll interval and otherwise does nothing visible. Nobody notices for weeks, which is the more dangerous outcome — image updates silently stop.
A log shipper keeps shipping but loses container name and label enrichment, so the logs still arrive and become much harder to search.

Sequence the change: stand up the proxy first, point the tool at DOCKER_HOST=tcp://socket-proxy:2375, confirm it works, and only then recreate without the direct mount. Rolling back is recreating with the mount, so keep the previous Compose file until the new one has survived a full poll cycle.