github.com/sijibomii/docker@v0.0.0-20231230191044-5cf6ca554647/docs/userguide/networking/default_network/container-communication.md

github.com/sijibomii/docker@v0.0.0-20231230191044-5cf6ca554647/docs/userguide/networking/default_network/container-communication.md (about)

1 
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 Many using Docker will want `ip_forward` to be on, to at least make
41 communication _possible_ between containers and the wider world. May also be
42 needed for inter-container communication if you are in a multiple bridge setup.
43
44 Docker will never make changes to your system `iptables` rules if you set
45 `--iptables=false` when the daemon starts. Otherwise the Docker server will
46 append forwarding rules to the `DOCKER` filter chain.
47
48 Docker will not delete or modify any pre-existing rules from the `DOCKER` filter
49 chain. This allows the user to create in advance any rules required to further
50 restrict access to the containers.
51
52 Docker's forward rules permit all external source IPs by default. To allow only
53 a specific IP or network to access the containers, insert a negated rule at the
54 top of the `DOCKER` filter chain. For example, to restrict external access such
55 that _only_ source IP 8.8.8.8 can access the containers, the following rule
56 could be added:
57
58 ```
59 $ iptables -I DOCKER -i ext_if ! -s 8.8.8.8 -j DROP
60 ```
61
62 where *ext_if* is the name of the interface providing external connectivity to the host.
63
64 ## Communication between containers
65
66 Whether two containers can communicate is governed, at the operating system level, by two factors.
67
68 - 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.
69
70 - 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`.
71
72 It is a strategic question whether to leave `--icc=true` or change it to
73 `--icc=false` so that `iptables` will protect other containers -- and the main
74 host -- from having arbitrary ports probed or accessed by a container that gets
75 compromised.
76
77 If you choose the most secure setting of `--icc=false`, then how can containers
78 communicate in those cases where you _want_ them to provide each other services?
79 The answer is the `--link=CONTAINER_NAME_or_ID:ALIAS` option, which was
80 mentioned in the previous section because of its effect upon name services. If
81 the Docker daemon is running with both `--icc=false` and `--iptables=true`
82 then, when it sees `docker run` invoked with the `--link=` option, the Docker
83 server will insert a pair of `iptables` `ACCEPT` rules so that the new
84 container can connect to the ports exposed by the other container -- the ports
85 that it mentioned in the `EXPOSE` lines of its `Dockerfile`.
86
87 > **Note**: The value `CONTAINER_NAME` in `--link=` must either be an
88 auto-assigned Docker name like `stupefied_pare` or else the name you assigned
89 with `--name=` when you ran `docker run`. It cannot be a hostname, which Docker
90 will not recognize in the context of the `--link=` option.
91
92 You can run the `iptables` command on your Docker host to see whether the `FORWARD` chain has a default policy of `ACCEPT` or `DROP`:
93
94 ```
95 # When --icc=false, you should see a DROP rule:
96
97 $ sudo iptables -L -n
98 ...
99 Chain FORWARD (policy ACCEPT)
100 target prot opt source destination
101 DOCKER all -- 0.0.0.0/0 0.0.0.0/0
102 DROP all -- 0.0.0.0/0 0.0.0.0/0
103 ...
104
105 # When a --link= has been created under --icc=false,
106 # you should see port-specific ACCEPT rules overriding
107 # the subsequent DROP policy for all other packets:
108
109 $ sudo iptables -L -n
110 ...
111 Chain FORWARD (policy ACCEPT)
112 target prot opt source destination
113 DOCKER all -- 0.0.0.0/0 0.0.0.0/0
114 DROP all -- 0.0.0.0/0 0.0.0.0/0
115
116 Chain DOCKER (1 references)
117 target prot opt source destination
118 ACCEPT tcp -- 172.17.0.2 172.17.0.3 tcp spt:80
119 ACCEPT tcp -- 172.17.0.3 172.17.0.2 tcp dpt:80
120 ```
121
122 > **Note**: Docker is careful that its host-wide `iptables` rules fully expose
123 containers to each other's raw IP addresses, so connections from one container
124 to another should always appear to be originating from the first container's own
125 IP address.