The answer, as with most things in security is, it depends. Here's some relevant information to see if this matters to you.
Docker provides a default bridge network (docker0
in a default install). This is just a standard Linux bridge network. your threat model is likely one of two scenarios
- The attacker has access to another container on the same bridge
- The attacker has access to the underlying host.
In both cases the attacker is going to need enough privilege to sniff traffic and/or ARP spoof on that network. This generally comes to to either having root
privileges on the host or having the NET_RAW
capability which is the one which is relevant to traffic sniffing and ARP Spoofing.
In case one, unfortunately (from a security standpoint) Docker gives all containers the NET_RAW
capability by default, so a default install, without hardening will allow an attacker with access to one container to attack other containers on that network. You can mitigate this by dropping NET_RAW
from the container privileges.
In case two, if the attacker has privileged access to the host running the containers, they can get access to that network, but then they can also get access to all your containers too, so you probably don't need to worry just about traffic sniffing :)
This is all assuming standard Docker networking, if you're using Kubernetes there are more variables at play as there are a variety of networking options available there.
Some good additional material on this topic. There's a whitepaper here which talks about this issue. Liz Rice did a good talk about this topic at Kubecon this year (video here).
One other note is that on the Docker default network, but not on any other networks created by Docker, you can set --icc=false
which prevents any inter container communication which isn't explicitly white-listed by links between containers. This is a legacy option though, so I wouldn't rely on it, going forwards.