docker-compose：在容器中打开端口但不从主机绑定它

Question

. Answers to this question are eligible for a +50 reputation bounty. doraemon wants to to this question.

I created a service (a small web server) using docker-compose . The network part is defined as

services:
  service:
    image: ... (this image uses port 9000)
    ports:
      - 9000:9000
networks:
  default:
    name: my-network

After docker-compose up , I observe:

• the host gets an IP address 127.22.0.1 and the client gets 127.22.0.2 .
• I can successfully ping the client from the host ping 127.22.0.2 .
• From the host machine: the web server can be reached using
  • 127.22.0.1:9000
  • 127.22.0.2:9000
  • localhost:9000
  • 192.168.0.10:9000 (This is the host's IP address in the LAN)

Now I want to restrict the access from the host using 127.22.0.2:9000 only. I feel this should be possible if I don't bind the container's 9000 port to the host's 9000 port. Then I deleted the ports: 9000:9000 part from the docker-compose.yml . Now I observe:

• All the above four methods do not work now, including 127.22.0.2:9000
• The client can still be pinged from the host using 127.22.0.2

I think: since the the host and the container are both in a bridge network my-network and have obtained their IP addresses. The web server should still be reachable from 127.22.0.2:9000 . But this is not the case.

My questions:

• why does it work like this? Shouldn't the host/container in the same subnet 127.22.0.0/16 be able to talk to each other freely?
• How to achieve what I want: do not forward port 9000 from host to container and only allow accessing the container using its subnet IP address.

Answer 1

Docker is also playing with your host iptables in order to achieve its isolation standarts.

These are the default iptables rules with no container running:

$ sudo iptables-save 
# Generated by iptables-save v1.8.4 on Tue Jan 11 13:11:52 2022
*filter
:INPUT ACCEPT [49:15900]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [53:4709]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Tue Jan 11 13:11:52 2022
# Generated by iptables-save v1.8.4 on Tue Jan 11 13:11:52 2022
*nat
:PREROUTING ACCEPT [3:1112]
:INPUT ACCEPT [3:1112]
:OUTPUT ACCEPT [11:899]
:POSTROUTING ACCEPT [11:899]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
COMMIT
# Completed on Tue Jan 11 13:11:52 2022

After running a container which binds on port 8080 you can see that 3 rules where added to my iptables rules:

$ sudo iptables-save 
# Generated by iptables-save v1.8.4 on Tue Jan 11 13:14:36 2022
*filter
:INPUT ACCEPT [79:25192]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [75:8565]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8080 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Tue Jan 11 13:14:36 2022
# Generated by iptables-save v1.8.4 on Tue Jan 11 13:14:36 2022
*nat
:PREROUTING ACCEPT [33:4634]
:INPUT ACCEPT [9:3254]
:OUTPUT ACCEPT [13:2363]
:POSTROUTING ACCEPT [13:2363]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 8080 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:8080
COMMIT
# Completed on Tue Jan 11 13:14:36 2022

So regarding question1: The reason your host/container can't talk to each other freely eventhough they are in the same subbet 127.22.0.0/16 is because of the iptables preventing it.

Regarding question2: You can play with docker iptables configuration in order to achieve your wanted behaviour. But IMO you should just bind port 9000 only on localhost instead see , that way it won't listen on your LAN

Answer 2

Your understanding of the networking is correct. Removing the port binding from the docker-compose.yml will remove the exposed port from the host. Since the host is also part of the virtual network my-network with an IP in the same subnet as the container, your service should be reachable from the host using the container IP directly.

But I think, this is actually a simple typo and instead of

127.22.0.0/16

you actually have

172.22.0.0/16

as the subnet for my-network ! This is a typical subnet used by docker in the default configuration, while 127.0.0.0/8 is always bound to the loopback device !

So connecting to 127.22.0.2 will actually connect you to localhost - which is consistent with the symptoms you encountered:

• connecting to 127.22.0.2:9000 will work only if the port is exposed on the host
• you can always pint 127.22.0.2 since it is the loopback address