Docker’s architecture is complex, with many configurations and controls that require careful scrutiny to keep secure.
The Docker daemon is the pivotal point in Docker architecture. Only trusted users should be allowed to interact with it since it mostly runs with root privileges (even if an experimental rootless mode is available in the latest versions). It does not actively limit the containers’ access rights to the host, meaning containers can be launched to access the host operating system’s resources, such as its file system or network stack.
For this reason, giving someone access to the Docker daemon is equivalent to giving them root access to the host operating system, and it is a decision that must be made with utmost caution.
Docker provides a REST API, called the Docker Engine API, to facilitate interaction with the Docker daemon via a UNIX socket or a TCP port. It is commonly used by the Docker CLI to communicate with the Docker daemon.
Utilizing the non-networked
/var/run/docker.sock UNIX socket is the default method of accessing the Docker Engine API locally. In the default Docker configuration in Linux, only “root” and users in the “docker” group can access the socket.
The Docker Engine API can be optionally exposed on the network, meaning everyone who can access the TCP port also has full access to the Docker daemon.
Avoiding the exposure of the Docker Engine API to the network is strongly recommended. Even if the TCP port is not reachable from the network, the daemon is still prone to Server-Side Request Forgery attacks, Privilege Escalation, and Container Breakout attacks staged from within compromised containers.
If exposing Docker is absolutely necessary for the network configuration, securing the API endpoints with HTTPS and certificates and ensuring it is reachable only from trusted networks is crucial.
Using port 2375 is conventional for unencrypted communication and port 2376 for encrypted communication with the daemon.