blog
Is exposing the Docker socket remotely safe?
Published
This question usually arrives as a practical one — "I want to manage my containers from my laptop, how do I reach the daemon?" The honest answer is that the daemon socket is not an API you should expose, and the reason is stronger than most people expect.
The short answer
No. Not on its own, and not on a port. Access to the Docker daemon is equivalent to root on the machine running it. Docker says so in its own documentation: anyone who can instruct your daemon has "root access to the machine hosting the daemon".
That is not a warning about a hypothetical bug. It is a description of what the daemon is designed to do.
What the socket actually grants
The daemon can mount any host path into a container without restricting the container's access rights. So anyone who can talk to it can mount the host root filesystem and step into it.
That is the whole escalation. No exploit, no privilege bug — just the documented feature set used against you.
What an exposed daemon on port 2375 hands to anyone who finds it
docker -H tcp://203.0.113.10:2375 run --rm -it \ -v /:/host alpine chroot /host sh
Read that command as the threat model, not as a trick: there is no authentication step in it. If the port answers, it works.
Port 2375 is the one that gets people
The unencrypted daemon port is 2375. It has no authentication and no transport security. Every tutorial that tells you to add -H tcp://0.0.0.0:2375 to your daemon flags is telling you to publish a root shell.
Scanners find these constantly. A server with 2375 open is not "probably fine because nobody knows the IP" — the whole address space is scanned continuously, and an open Docker port is one of the highest-value things to find.
TLS on 2376 is authentication, not harmlessness
The supported way to expose the daemon is TLS on port 2376 with mutual certificate authentication. The daemon then "only allows connections from clients authenticated by a certificate signed by that CA".
This genuinely fixes the "anyone who finds the port" problem. It does not change what a client can do once connected. Docker's own instruction is blunt about the consequence: "Guard these keys as you would a root password!"
So you now own a certificate authority. You issue client certs, distribute them, keep them off shared machines, rotate them when a laptop is lost, and revoke them when someone leaves. That is real work, and Docker itself calls managing a CA an advanced topic.
The alternative most people actually want
You already have an authenticated, encrypted, key-based channel to that server: SSH. Docker can use it directly, with no new port, no daemon flags and no certificate authority.
Reaching a remote daemon over the SSH access you already have
docker context create my-vps \ --docker "host=ssh://deploy@203.0.113.10" docker context use my-vps docker ps
The daemon stays on its local UNIX socket. Nothing new listens on the network, and access is governed by the SSH keys you already manage.
What this means for a management tool
Any tool that manages remote containers has to answer this question somehow. The answers are: expose the daemon and take on the CA, install an agent on the server that holds the credentials, or drive the machine over SSH the way you would by hand.
MihraOps takes the third one. It opens an ordinary SSH connection from your computer and runs ordinary commands. There is no daemon port to open, no certificate authority to run, and no panel on the server holding your keys — they stay on your machine, in your operating system's encrypted storage.
That choice has a real cost, and it is worth stating: nothing of ours is running while the app is closed, so there is no server-side dashboard to check from your phone. If you need that, a server-side platform is the better fit and the comparison pages say so.