10

On normal networks, it is a security risk to send plaintext data, since attackers can sniff or even manipulate all traffic. Encryption is required for secure communication. When using Docker containers, these can be connected together using virtual network interfaces. Do these suffer from the same security problems, or are Docker network connections secure against sniffing? Is it necessary to encrypt traffic over the Docker network?

Edit: I am interested in whether the traffic between two docker containers can be intercepted by a third docker container, when all are on the same bridge network on the same host.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • See also [Docker Container's network interface in promiscuous mode](https://stackoverflow.com/questions/40130356/docker-containers-network-interface-in-promiscuous-mode). – Sjoerd Dec 12 '19 at 15:39

3 Answers3

7

Yes, you need to secure the traffic.

Reading docs.docker.com:

"if you need Docker to be reachable through the network in a safe manner, you can enable TLS by specifying the tlsverify flag and pointing Docker’s tlscacert flag to a trusted CA certificate. In the daemon mode, it only allows connections from clients authenticated by a certificate signed by that CA. In the client mode, it only connects to servers with a certificate signed by that CA."

In the article Top 20 Docker Security Tips by Jeff Hale, the author writes

"Docker provides private container networking, too. This prevents a container from gaining privileged access to the network interfaces of other containers on the same host. So a Docker environment comes somewhat isolated, but it might not be isolated enough for your use case."

The article brings more ideas for strenghtening Docker security, including:

  1. limiting privileges
  2. avoiding running as root
  3. using trusted and signed images
  4. using minimal images and resources
  5. managing keys securely
  6. updating libraries
  7. considering Docker Enterprise

Source:

LLub
  • 1,246
  • 10
  • 21
  • My answer is focusing only on one aspect of the security. If you aim for a secure solution, I would also recommend to seek for a "multi-layered security" strategy with "defence in depth". Securing the data in transit meaning securing the network traffic is only one element of the bigger puzzle: data at rest and in transit, key encryption and storage, identification and authentication, authorization, roles and responsibilities, segregation of duties, as well as system and application patching, virtual network, firewall, vpn and db configuration, enabling AppArmor, SELinux, GRSEC, etc. – LLub Dec 09 '19 at 14:50
  • 1
    I think the OP is more asking about the "network" connections between containers in the same host, which are (probably) not going to be leaving the box, and thus aren't network reachable. – Clockwork-Muse Dec 09 '19 at 18:33
  • 2
    This doesn't really answer my question. I am interested in whether the traffic between two docker containers can be intercepted by a third docker container, when all are on the same bridge network on the same host. – Sjoerd Dec 12 '19 at 10:15
5

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

  1. The attacker has access to another container on the same bridge
  2. 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.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
1

You need to take into account that docker containers can share a bridge device, so all the traffic from one container can be sniffed from another one if both reside on the same host.

Another variable to take into consideration is bugs. The docker host can have a bug that allows a docker instance to sniff traffic that should not be allowed. So the best is to encrypt the traffic if you are considering that scenario.

guntbert
  • 1,825
  • 2
  • 18
  • 21
camp0
  • 2,172
  • 1
  • 10
  • 10
  • Is it necessarily the case that if dockers share a bridge device they can see each other's traffic? With normal switches this is possible through ARP spoofing. Would that work on the docker network? It doesn't have a conventional switch. Does it even has layer 2 networking? – Sjoerd Dec 12 '19 at 10:16