Contexts & Remote Engines

## The API is the security boundary, and it is root-shaped `dockerd` normally listens on `/var/run/docker.sock`, a unix socket whose file permissions - root, group `docker` - are the entire access-control system. Adding `-H tcp://0.0.0.0:2375` puts that same API on a TCP port with **no authentication whatsoever**. There is no user, no password, no token, no per-verb permission in the Engine API. Reaching it is the authorization. And what it authorizes is not "managing containers", it is the host. A caller who can reach the API can start a container with the host's root filesystem bind-mounted and extra privileges, at which point every file on the machine is readable and writable - private keys, database credentials, `/etc/shadow`, another user's home directory - and adding a key to root's `authorized_keys` turns API access into a root login. Nothing about images or containers needs to be understood to do this; it is one `docker run` away. This is why open 2375 is not a theoretical finding. Internet-wide scanners look for it continuously, and an exposed daemon is typically found and used to run mining or botnet containers in minutes to hours, not weeks. "It is only on the office network" is a weaker mitigation than it sounds, because it means every laptop, CI runner and compromised browser on that network holds root on the build host. ## Convention: 2375 is plaintext, 2376 is TLS The ports are only a convention, but a universally followed one. 2375 is the unencrypted API; 2376 is the TLS-protected one. Seeing 2375 in a systemd drop-in or a cloud image is itself the finding. ## Option 1: ssh:// - usually the right answer ``` docker context create build-host --docker "host=ssh://[email protected]" ``` This opens no new listening port at all. The CLI reaches the remote engine through the SSH service that is already there and already managed: per-user keys, key rotation and revocation, a real user identity in the logs, and whatever multi-factor or bastion policy the organisation already applies to shells. Authorization on the far side is still just membership of the `docker` group, so it remains a root-equivalent grant, but you now know *which* human or robot used it and you can withdraw one key without reissuing anything to anyone else. For a small team sharing one build host, this is almost always the correct choice, and it is the default recommendation for that reason. ## Option 2: mutual TLS on 2376 When SSH is not available - a daemon consumed by a tool that speaks the API directly, for example - TLS with client certificates is the built-in mechanism: ``` dockerd --tlsverify \ --tlscacert=/etc/docker/ca.pem \ --tlscert=/etc/docker/server-cert.pem \ --tlskey=/etc/docker/server-key.pem \ -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock ``` The distinction that matters: `--tls` turns on encryption but verifies no client, so it stops eavesdropping and stops nothing else. `--tlsverify` additionally requires the client to present a certificate signed by the CA in `--tlscacert`, which is what actually turns "anyone on the network" into "holders of an issued key". On the client side, `DOCKER_TLS_VERIFY=1` plus `DOCKER_CERT_PATH` pointing at a directory containing `ca.pem`, `cert.pem` and `key.pem`, or the same material baked into a context so it travels with the endpoint name. Two caveats. A client certificate is all-or-nothing - the API has no roles, so a certificate issued for "just running builds" is also a certificate for reading every file on the host. And you now own a small CA: issuing, distributing, expiring and revoking keys, with revocation being the part teams reliably forget. ## Defence in depth around either choice Bind the listener to a private interface rather than `0.0.0.0` whenever a network endpoint is needed at all, and put a host firewall in front of it so reachability is an explicit allowlist. If a genuinely restricted API surface is required, an authorization plugin can gate individual API calls - but treat that as a specialist control rather than the baseline. And keep the daemon's own configuration honest: specifying listen addresses both as a `dockerd` flag and in the daemon configuration file makes the daemon refuse to start with a complaint that the directive is given twice. ## In a review, the checklist is short Is anything listening on 2375? Is a TCP listener bound to `0.0.0.0`? Is `--tlsverify` present, or only `--tls`? Who holds client keys, and what happens when one leaks? If the answer to the last question is "we would reissue everyone's", that is an argument for `ssh://`.