Docker API Explained: Remote Control of Containers & Exposed Docker Daemons (Animated)

Every docker command is really an HTTP request to the Docker engine’s API. Normally that API listens only on a local socket. When it is opened on the network without authentication, anyone who reaches it can start containers with full control of the host, a very common cloud breach.

1. Cli → api: every command is an http request

Running “docker ps” sends GET /containers/json to the engine. Here the admin connects securely over SSH.

1. GET (DevOps laptop → Docker host): The CLI calls the API.
2. 200 OK (Docker host → DevOps laptop): The engine answers.

Wireshark filter:

http.request.uri contains "/containers"

2. Create a container: two api calls start a workload

Creating and starting a container is a POST with a JSON description: image, ports, volumes, privileges.

1. POST (DevOps laptop → Docker host): The admin starts a normal, unprivileged container.
2. 201 CREATED (Docker host → DevOps laptop): Created and then started.

Wireshark filter:

http.request.method == "POST"

3. Exposed docker api: attack: anyone can be the admin

Someone enabled the API on TCP 2375 to make remote work easier. It has no login. Internet scanners find it within hours; attackers start their own containers (often crypto-miners) and can give a container access to the host’s files, effectively taking over the server.

1. GET (Attacker → Docker host): The attacker confirms an open engine.
2. POST (Attacker → Docker host): The attacker starts its own container.

Wireshark filter:

tcp.dstport == 2375

4. Lock the daemon: defence: local socket, ssh or mutual tls

Never expose 2375. Manage remote engines over SSH or with mutual TLS on 2376, firewall the port, run rootless Docker where possible, and alert on API access from unknown addresses.

1. GET (Attacker → Docker host): Nothing answers on 2375.

Safe remote access:

export DOCKER_HOST=ssh://admin@203.0.113.75
dockerd: --tlsverify --tlscacert … (port 2376 only)

FAQ