Safer Local Docker Networks

TL;DR Prevent arbitrary inter-container communication by setting icc=false and using container linking.

If you enjoy or learn something from this article, consider buying my book, Docker in Action. It will be the Manning deal of the day (48 hours) on January 6th using promo code: dotd010615au.

Last week I wrote, Exploring Local Docker Bridge Networks. In that article I described how to use nmap to explore the services exposed by other containers on the same bridge network. I showed that this is possible even in cases where those services were not mapped to ports on the host’s public interface. This is an issue because most images for tools, databases, and microservices ship with insecure default configurations. Less paranoid engineers or admins might put these images into use under the impression that firewalls or network topology will protect them. This can only begin to hold true if you configure those firewalls and network topologies to do so.

By default Docker allows arbitrary inter-container communication. It is my opinion that this is a good thing. It reduces friction in adoption and reduces the learning curve. I think it is important for people to get started easily with any technology and have clear paths for developing their understanding going forward.

One such path is in understanding how to strengthen their container networks. The first thing people should learn is how to disable arbitrary inter-container communication. When you start the Docker daemon set icc=false.

docker -d --icc=false ....

When you start Docker this way, it will configure iptables (your firewall) to drop any traffic between container interfaces on the bridge network. This will prevent any communication between containers.

Chain FORWARD (policy ACCEPT)
target prot opt source    destination 
DROP   all  --  0.0.0.0/0 0.0.0.0/0 
ACCEPT all  --  0.0.0.0/0 0.0.0.0/0   ctstate RELATED,ESTABLISHED
ACCEPT all  --  0.0.0.0/0 0.0.0.0/0

This is appropriate if you never want your containers to be able to communicate with each other directly. There is nothing that would prevent communication out and back through the host’s public interface to publicly accessible ports that are mapped into another container.

Out and back again with exposed host ports.

For many, this would be enough. But the story doesn’t end here.

It is possible to make explicit connections between containers when inter-container communication is disabled. You do this at container creation time using container linking.

When you create one container specifying another as the target of a link, Docker builds the appropriate linkage. For example:

docker run -d --name ex_a busybox /bin/sh
docker run -d --name ex_b --link ex_a:other busybox /bin/sh

If I can say I’m unenthusiastic about any part of Docker today, it would be using container links for service discovery. When you link two containers environment variables with location details are set for the consuming container. The issue is that there are too many implicit contracts at work. The program or user creating the consuming container specifies the link aliases. But the software inside the container must agree with that alias otherwise it will not know what to look for. Even when I consider that links provide port information as well as network address information, I still prefer DNS. Fortunately, links are not just for service discovery.

Docker creates explicit exceptions for communication between linked containers when you’ve disabled inter-container communication. The following is an example from iptables with such an exception.

Chain FORWARD (policy ACCEPT)
target prot opt source     destination 
ACCEPT tcp  --  172.17.0.3 172.17.0.4  tcp spt:80
ACCEPT tcp  --  172.17.0.4 172.17.0.3  tcp dpt:80
DROP   all  --  0.0.0.0/0  0.0.0.0/0 
ACCEPT all  --  0.0.0.0/0  0.0.0.0/0   ctstate RELATED,ESTABLISHED
ACCEPT all  --  0.0.0.0/0  0.0.0.0/0

This is the most powerful use of container linking. Links allow you to define relationships between containers with simple assertions. Simplicity is something that Docker does better than any other tool I’ve used.

Anyway, get back to work and make sure that you’ve protected yourself in the new year.