search

moby / libnetwork

networking for containers
Apache License 2.0
2.16k stars 882 forks source link

Docker containers in different networks (bridge and Swarm overlay) are able to connect when they shouldn't be #1859

Open Deepak-Vohra opened 7 years ago

Deepak-Vohra commented 7 years ago

Description

Docker container in Swarm overlay default network is able to connect to or ping Docker container in bridge network created with docker run.

Steps to reproduce the issue:

  1. Create a Docker service in Swarm mode. 
    core@ip-172-30-2-7 ~ $ docker service create \
>   --env MYSQL_ROOT_PASSWORD='mysql'\
>   --replicas 1 \
>   --name mysql \
>  mysql
42nyazksad09kkxe1rf0hvtdj
  2. Create a standalone Docker container. 
    core@ip-172-30-2-7 ~ $ docker run --name mysqldb  -itd  -e MYSQL_DATABASE='mysqldb' -e MYSQL_USER='mysql' -e MYSQL_PASSWORD='mysql' -e MYSQL_ALLOW_EMPTY_PASSWORD='no' -e MYSQL_ROOT_PASSWORD='mysql' mysql
ef964596c0bdbd6f9ae0d4c24f8cbf5068e42d1354f9d52a8f82d570a8461169
  3. List Docker containers for the service and standalone.
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
ef964596c0bd        mysql               "docker-entrypoint.sh"   4 seconds ago       Up 3 seconds        3306/tcp            mysqldb
af47fd62d693        mysql:latest        "docker-entrypoint.sh"   4 minutes ago       Up 4 minutes        3306/tcp            mysql.1.3d8nvc8kgtvkuxxrvf2w3l6au
  1. Ping Standalone container from Docker service container and vice versa.

Describe the results you received:

core@ip-172-30-2-7 ~ $ docker exec -it ef964596c0bd bash
root@ef964596c0bd:/# ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2): 56 data bytes
64 bytes from 172.17.0.2: icmp_seq=0 ttl=64 time=0.085 ms
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.071 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.080 ms
64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.073 ms
64 bytes from 172.17.0.2: icmp_seq=4 ttl=64 time=0.069 ms
64 bytes from 172.17.0.2: icmp_seq=5 ttl=64 time=0.071 ms
64 bytes from 172.17.0.2: icmp_seq=6 ttl=64 time=0.070 ms
64 bytes from 172.17.0.2: icmp_seq=7 ttl=64 time=0.049 ms
^C--- 172.17.0.2 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.049/0.071/0.085/0.000 ms
root@ef964596c0bd:/# exit
exit
core@ip-172-30-2-7 ~ $ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'  ef964596c0bd
172.17.0.3
core@ip-172-30-2-7 ~ $ docker exec -it af47fd62d693 bash
root@af47fd62d693:/# ping 172.17.0.3                                           
PING 172.17.0.3 (172.17.0.3): 56 data bytes
64 bytes from 172.17.0.3: icmp_seq=0 ttl=64 time=0.083 ms
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.17.0.3: icmp_seq=3 ttl=64 time=0.052 ms
64 bytes from 172.17.0.3: icmp_seq=4 ttl=64 time=0.068 ms
64 bytes from 172.17.0.3: icmp_seq=5 ttl=64 time=0.048 ms
64 bytes from 172.17.0.3: icmp_seq=6 ttl=64 time=0.070 ms
^C--- 172.17.0.3 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.048/0.065/0.083/0.000 ms

Describe the results you expected:

As the Docker containers are in different networks (overlay and bridge they shouldn't be able to connect directly)

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:


core@ip-172-30-2-163 ~ $ docker --version
Docker version 1.12.6, build a82d35e

Output of docker info:


core@ip-172-30-2-163 ~ $ docker info
Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.6
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: active

Additional environment details (AWS, VirtualBox, physical, etc.): CoreOS Stable 3 Instances

core@ip-172-30-2-7 ~ $ docker node ls
ID                           HOSTNAME                      STATUS  AVAILABILITY  MANAGER STATUS
1v5xo9a5qotjqby4tm22oxr6h    ip-172-30-2-171.ec2.internal  Ready   Active        
3ncsjq5v2urg78jjm75aydldi *  ip-172-30-2-7.ec2.internal    Ready   Active        Leader
ae9jr8vj6s3hpy2v6yjmcmdst    ip-172-30-2-163.ec2.internal  Ready   Active        
core@ip-172-30-2-7 ~ $ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
a28b3d48c764        bridge              bridge              local               
07b1daefd44a        docker_gwbridge     bridge              local               
e361ccca6077        host                host                local               
01tcqnl6eclq        ingress             overlay             swarm               
ed5e712689cd        none                null                local
talex5 commented 6 years ago

I believe that overlay networks are only used for container-to-container communication. Therefore, containers on an overlay network will typically also be on a bridge network, for communication with the outside world. Looking at the IP addresses of your two containers (172.17.0.2 and 172.17.0.3) I'd guess they're both on the same bridge.

Actually, are you sure the service task is on an overlay network at all? I don't think there is a default overlay network, and it doesn't look like you specified one explicity when you created the service.

tconrado commented 5 years ago

the best way to understand this situation is to inspect the docker networks. Swarm use the overlay + docker_gwbridge (this is proper to connect to host). You can guarantee total isolation by creating your overlay with the --internal option