Maksym Yemelyanov - stock.adobe.
Get informed of the risks associated with docker.sock
Container security is a new area for many IT admins, and enterprise IT organizations can easily set up Docker in ways that compromise access control -- potentially exposing the host.
While admins can gain deployment flexibility when they run the Docker Unix socket inside a container, that model carries some risk.
A socket is an endpoint in a network that passes data between software. Docker.sock is a Unix socket that enables the Docker server-side daemon, dockerd, to communicate with its command-line interface via a REST API.
The socket appears as the /var/run/docker.sock file. Because it is a file, admins can share and run docker.sock within a container and then use it to communicate with that container. A container that runs docker.sock can start or stop other containers, create images on the host or write to the host file system.
However, running docker.sock from within a container also poses security risks.
Risks surrounding docker.sock within a container
Docker.sock could increase a container's attack surface and thereby compromise the host.
If an unauthorized user gains access to a container that runs docker.sock, he would gain root access privileges for the host and Docker. A root user can alter the host as they please. Additionally, because docker.sock enables users to start, stop and otherwise manipulate containers, an unauthorized user could execute any Docker command. What's more, if that user can access the Docker socket, he can listen in on, or connect to, the API.
How to safely use docker.sock
The best way to avoid these security risks is to not use docker.sock at all. However, if an organization must use docker.sock, then it should follow best practices.
Before mounting docker.sock to a container, carefully consider the information that containers will share -- the more sensitive the information in the Docker image, the bigger the risk. Only grant the container access to the information it needs when using docker.sock. At the least, set information within a container to read-only, as this will prevent an unauthorized user from changing any content. However, this would not stop a user from gaining root access to the underlying host.
To restrict operations by user, enable the Transport Layer Security or authorization proxies. Docker also can block access to a socket through HTTP and provide additional authentication and authorization features via role-based access control configurations. Additionally, use Docker Bench for Security, an automated auditing script from Docker Inc. that checks the deployment against Center for Internet Security benchmarks and best practices around container deployment.
Docker.sock alternatives
While there are not many direct alternatives to docker.sock, proxies can add more security features.
HAProxy is an open source load balancer for TCP and HTTP applications. Admins can set up HAProxy to listen to docker.sock, as well as configure it to support specified endpoints or remove docker.sock access.
Another option is docker-proxy-acl, a Unix socket proxy that can restrict or enable access to endpoints, including containers, images, volumes, events, tasks and networks. Docker-proxy-acl can also prevent users from building additional Dockerfiles, where they could provide malicious instructions to a Docker container image.
