github.com/kobeld/docker@v1.12.0-rc1/docs/userguide/networking/default_network/container-communication.md (about) 1 <!--[metadata]> 2 +++ 3 title = "Understand container communication" 4 description = "Understand container communication" 5 keywords = ["docker, container, communication, network"] 6 [menu.main] 7 parent = "smn_networking_def" 8 +++ 9 <![end-metadata]--> 10 11 # Understand container communication 12 13 The information in this section explains container communication within the 14 Docker default bridge. This is a `bridge` network named `bridge` created 15 automatically when you install Docker. 16 17 **Note**: The [Docker networks feature](../dockernetworks.md) allows you to create user-defined networks in addition to the default bridge network. 18 19 ## Communicating to the outside world 20 21 Whether a container can talk to the world is governed by two factors. The first 22 factor is whether the host machine is forwarding its IP packets. The second is 23 whether the host's `iptables` allow this particular connection. 24 25 IP packet forwarding is governed by the `ip_forward` system parameter. Packets 26 can only pass between containers if this parameter is `1`. Usually you will 27 simply leave the Docker server at its default setting `--ip-forward=true` and 28 Docker will go set `ip_forward` to `1` for you when the server starts up. If you 29 set `--ip-forward=false` and your system's kernel has it enabled, the 30 `--ip-forward=false` option has no effect. To check the setting on your kernel 31 or to turn it on manually: 32 ``` 33 $ sysctl net.ipv4.conf.all.forwarding 34 net.ipv4.conf.all.forwarding = 0 35 $ sysctl net.ipv4.conf.all.forwarding=1 36 $ sysctl net.ipv4.conf.all.forwarding 37 net.ipv4.conf.all.forwarding = 1 38 ``` 39 40 > **Note**: this setting does not affect containers that use the host 41 > network stack (`--net=host`). 42 43 Many using Docker will want `ip_forward` to be on, to at least make 44 communication _possible_ between containers and the wider world. May also be 45 needed for inter-container communication if you are in a multiple bridge setup. 46 47 Docker will never make changes to your system `iptables` rules if you set 48 `--iptables=false` when the daemon starts. Otherwise the Docker server will 49 append forwarding rules to the `DOCKER` filter chain. 50 51 Docker will not delete or modify any pre-existing rules from the `DOCKER` filter 52 chain. This allows the user to create in advance any rules required to further 53 restrict access to the containers. 54 55 Docker's forward rules permit all external source IPs by default. To allow only 56 a specific IP or network to access the containers, insert a negated rule at the 57 top of the `DOCKER` filter chain. For example, to restrict external access such 58 that _only_ source IP 8.8.8.8 can access the containers, the following rule 59 could be added: 60 61 ``` 62 $ iptables -I DOCKER -i ext_if ! -s 8.8.8.8 -j DROP 63 ``` 64 65 where *ext_if* is the name of the interface providing external connectivity to the host. 66 67 ## Communication between containers 68 69 Whether two containers can communicate is governed, at the operating system level, by two factors. 70 71 - Does the network topology even connect the containers' network interfaces? By default Docker will attach all containers to a single `docker0` bridge, providing a path for packets to travel between them. See the later sections of this document for other possible topologies. 72 73 - Do your `iptables` allow this particular connection? Docker will never make changes to your system `iptables` rules if you set `--iptables=false` when the daemon starts. Otherwise the Docker server will add a default rule to the `FORWARD` chain with a blanket `ACCEPT` policy if you retain the default `--icc=true`, or else will set the policy to `DROP` if `--icc=false`. 74 75 It is a strategic question whether to leave `--icc=true` or change it to 76 `--icc=false` so that `iptables` will protect other containers -- and the main 77 host -- from having arbitrary ports probed or accessed by a container that gets 78 compromised. 79 80 If you choose the most secure setting of `--icc=false`, then how can containers 81 communicate in those cases where you _want_ them to provide each other services? 82 The answer is the `--link=CONTAINER_NAME_or_ID:ALIAS` option, which was 83 mentioned in the previous section because of its effect upon name services. If 84 the Docker daemon is running with both `--icc=false` and `--iptables=true` 85 then, when it sees `docker run` invoked with the `--link=` option, the Docker 86 server will insert a pair of `iptables` `ACCEPT` rules so that the new 87 container can connect to the ports exposed by the other container -- the ports 88 that it mentioned in the `EXPOSE` lines of its `Dockerfile`. 89 90 > **Note**: The value `CONTAINER_NAME` in `--link=` must either be an 91 auto-assigned Docker name like `stupefied_pare` or else the name you assigned 92 with `--name=` when you ran `docker run`. It cannot be a hostname, which Docker 93 will not recognize in the context of the `--link=` option. 94 95 You can run the `iptables` command on your Docker host to see whether the `FORWARD` chain has a default policy of `ACCEPT` or `DROP`: 96 97 ``` 98 # When --icc=false, you should see a DROP rule: 99 100 $ sudo iptables -L -n 101 ... 102 Chain FORWARD (policy ACCEPT) 103 target prot opt source destination 104 DOCKER all -- 0.0.0.0/0 0.0.0.0/0 105 DROP all -- 0.0.0.0/0 0.0.0.0/0 106 ... 107 108 # When a --link= has been created under --icc=false, 109 # you should see port-specific ACCEPT rules overriding 110 # the subsequent DROP policy for all other packets: 111 112 $ sudo iptables -L -n 113 ... 114 Chain FORWARD (policy ACCEPT) 115 target prot opt source destination 116 DOCKER all -- 0.0.0.0/0 0.0.0.0/0 117 DROP all -- 0.0.0.0/0 0.0.0.0/0 118 119 Chain DOCKER (1 references) 120 target prot opt source destination 121 ACCEPT tcp -- 172.17.0.2 172.17.0.3 tcp spt:80 122 ACCEPT tcp -- 172.17.0.3 172.17.0.2 tcp dpt:80 123 ``` 124 125 > **Note**: Docker is careful that its host-wide `iptables` rules fully expose 126 containers to each other's raw IP addresses, so connections from one container 127 to another should always appear to be originating from the first container's own 128 IP address.