0

I am using docker to run containers.
I don't want the containers to have access to the other containers but I want them to still have access to external communication like using apt update.

The containers network is 172.17.0.0/16, if I just block like that:

iptables -I FORWARD -i docker0 -d 172.17.0.0/16 -j DROP

It works but then they can't use apt update, it can't find from where to download because it probably goes out from the gateway.
Therefore I wanted to allow connection to the gateway (172.17.0.1) so I tried to allow it like that:

iptables -A INPUT -i docker0 -d 172.17.0.1/32 -j ACCEPT
iptables -A OUTPUT -o docker0 -d 172.17.0.1/32 -j ACCEPT

But the problem still exist, it can't use apt update:

Err:1 http://archive.ubuntu.com/ubuntu focal InRelease
  Temporary failure resolving 'archive.ubuntu.com'

Only when I remove the block rule it works again:

iptables -I FORWARD -i docker0 -d 172.17.0.0/16 -j DROP
E235
  • 111
  • 3
  • I can't reproduce your problem. Running two debian containers with 172.17.0.2 and 172.17.0.3 on docker0, they can't communicate with your FORWARD DROP rule (that's because Docker activates `net.bridge.bridge-nf-call-iptables` by the way), but they don't have any issue to reach the host through 172.17.0.1 , including DNS requests, or successfully running `apt update` and `apt install hello`. – A.B Jul 04 '21 at 12:42
  • Maybe you have other blocking rules and you just need as you did with FORWARD, to replace these `-A` by `-I`. – A.B Jul 04 '21 at 12:46
  • Or your DNS is handled by a container... or a proxy... you'll have to do separate tests with IP and DNS to figure out what's wrong – A.B Jul 04 '21 at 12:51
  • And last but not least comment: you're supposed to create additional networks and run containers in them for isolation rather than having to fiddle yourself (instead of Docker) with rules. https://docs.docker.com/network/network-tutorial-standalone/#use-user-defined-bridge-networks – A.B Jul 04 '21 at 12:57

1 Answers1

0

This will allow you to stop communications between containers:

Create a network with ICC disabled:

docker network create -o com.docker.network.bridge.enable_icc=false my_secure_bridge

Test with creating two containers:

docker run --name cnt1 --network=my_secure_bridge -it --rm -d alpine
docker run --name cnt2 --network=my_secure_bridge -it --rm -d alpine

docker inspect cnt1 | grep -i 172
    "Gateway":   "172.19.0.1",
    "IPAddress": "172.19.0.2",

docker inspect cnt2 | grep -i 172
    "Gateway":   "172.19.0.1",
    "IPAddress": "172.19.0.3",

exec into one and check:

docker exec -it cnt1 sh

check connectivity to outer world:

/ # ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=114 time=0.852 ms
64 bytes from 8.8.8.8: seq=1 ttl=114 time=0.990 ms
64 bytes from 8.8.8.8: seq=2 ttl=114 time=0.808 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.808/0.883/0.990 ms

check connectivity to another container:

/ # ping -w 5 172.19.0.3
PING 172.19.0.3 (172.19.0.3): 56 data bytes
--- 172.19.0.3 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
jabbson
  • 720
  • 2
  • 9
  • but what will the security benefit, in case of the container cant connect each other? – djdomi Jul 06 '21 at 04:47
  • @djdomi, the benefit is that this will solve the problem in the description, where the topic starter stated, that they "want the containers to have access to the other containers but I want them to still have access to external communication". – jabbson Jul 06 '21 at 12:52
  • write typo accident? you say to all have to access anywhere, that's a default behavior if correctly configured? – djdomi Jul 06 '21 at 16:09