dockerd --iptables=false adds DOCKER-USER chain and modify FORWARD chain anyway

[ass3mbler]

Issue description

• This is a bug report

dockerd (in Docker version 17.09.0-ce, build afdb6d4) still adds the DOCKER-USER chain and modifies the FORWARD chain of the system, even when specifying the --iptables=false command line option. From the documentation:

--iptables=false prevents the Docker daemon from adding iptables rules.

Actual behavior

1. Initial system state

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

2. dockerd startup

# dockerd                        --bridge=$BRIDGE_FOR_DOCKER                        \
                        --default-gateway=$VLAN_GW                     \
                        --dns=$VLAN_GW                                         \
                        --ip-forward=false                                         \
                        --ip-masq=false                                             \
                        --iptables=false                                              

3. System state AFTER dockerd is started

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Output of docker version:

# docker --version
Docker version 17.09.0-ce, build afdb6d4

Output of dockerd: with log-level=debug

[...]
INFO[2017-10-18T19:29:00.127161968+02:00] Graph migration to content-addressability took 0.00 seconds
INFO[2017-10-18T19:29:00.128425657+02:00] Loading containers: start.
DEBU[2017-10-18T19:29:00.128541730+02:00] Option Experimental: false
DEBU[2017-10-18T19:29:00.128561767+02:00] Option DefaultDriver: bridge
DEBU[2017-10-18T19:29:00.128572980+02:00] Option DefaultNetwork: bridge
DEBU[2017-10-18T19:29:00.128601637+02:00] Network Control Plane MTU: 1500
DEBU[2017-10-18T19:29:00.137265625+02:00] Network (3d1968a) restored
DEBU[2017-10-18T19:29:00.147812823+02:00] Allocating IPv4 pools for network bridge (3d1968a69f6a809c876dd48f6863406bd98975bb0c766f56ca195a2d26e6c396)
DEBU[2017-10-18T19:29:00.147914464+02:00] RequestPool(LocalDefault, 10.0.110.0/24, , map[], false)
DEBU[2017-10-18T19:29:00.147981078+02:00] RequestAddress(LocalDefault/10.0.110.0/24, 10.0.110.7, map[RequestAddressType:com.docker.network.gateway])
DEBU[2017-10-18T19:29:00.148074662+02:00] RequestAddress(LocalDefault/10.0.110.0/24, 10.0.110.254, map[])
DEBU[2017-10-18T19:29:00.238350415+02:00] releasing IPv4 pools from network bridge (3d1968a69f6a809c876dd48f6863406bd98975bb0c766f56ca195a2d26e6c396)
DEBU[2017-10-18T19:29:00.238400391+02:00] ReleaseAddress(LocalDefault/10.0.110.0/24, 10.0.110.7)
DEBU[2017-10-18T19:29:00.238434285+02:00] ReleaseAddress(LocalDefault/10.0.110.0/24, 10.0.110.254)
DEBU[2017-10-18T19:29:00.238455487+02:00] ReleasePool(LocalDefault/10.0.110.0/24)
DEBU[2017-10-18T19:29:00.271778370+02:00] cleanupServiceBindings for 3d1968a69f6a809c876dd48f6863406bd98975bb0c766f56ca195a2d26e6c396
DEBU[2017-10-18T19:29:00.338727790+02:00] Allocating IPv4 pools for network bridge (b942ab7220a3a9d38c8edeb316d726f320a303c6fd51558e8e6ae068841642ce)
DEBU[2017-10-18T19:29:00.338785268+02:00] RequestPool(LocalDefault, 10.0.110.0/24, , map[], false)
DEBU[2017-10-18T19:29:00.338846284+02:00] RequestAddress(LocalDefault/10.0.110.0/24, 10.0.110.7, map[RequestAddressType:com.docker.network.gateway])
DEBU[2017-10-18T19:29:00.338894801+02:00] RequestAddress(LocalDefault/10.0.110.0/24, 10.0.110.254, map[])
DEBU[2017-10-18T19:29:00.443906556+02:00] Fail to initialize firewalld: Failed to connect to D-Bus system bus: dial unix /var/run/dbus/system_bus_socket: connect: no such file or directory, using raw iptables instead
DEBU[2017-10-18T19:29:00.447774069+02:00] /sbin/iptables, [--wait -t filter -n -L DOCKER-USER]
DEBU[2017-10-18T19:29:00.449089436+02:00] /sbin/iptables, [--wait -t filter -N DOCKER-USER]
DEBU[2017-10-18T19:29:00.450484274+02:00] /sbin/iptables, [--wait -t filter -C DOCKER-USER -j RETURN]
DEBU[2017-10-18T19:29:00.451875755+02:00] /sbin/iptables, [--wait -A DOCKER-USER -j RETURN]
DEBU[2017-10-18T19:29:00.453289482+02:00] /sbin/iptables, [--wait -t filter -C FORWARD -j DOCKER-USER]
DEBU[2017-10-18T19:29:00.454704161+02:00] /sbin/iptables, [--wait -I FORWARD -j DOCKER-USER]
INFO[2017-10-18T19:29:00.456151567+02:00] Loading containers: done.
INFO[2017-10-18T19:29:00.494739068+02:00] Docker daemon                                 commit=afdb6d4 graphdriver(s)=overlay2 version=17.09.0-ce
INFO[2017-10-18T19:29:00.494885547+02:00] Daemon has completed initialization
[...]

[oandrew]

I have the same problem.

Looks like there is no check for the value of config.EnableIPTables.
https://github.com/docker/libnetwork/blob/f31bed11427ef107a7393c501cf8f6f0bee89463/controller.go#L885-L887

[axblum]

This also appears to be affecting docker version 17.12.0-ce as well

[vfrans]

Same on Docker version 17.12.1-ce, build 7390fc6

[cwedgwood]

also 18.03.0-ce

[adamhj]

Same on Docker version 18.03.1-ce, build 9ee9f40

[pineda89]

+1

[vladshved]

this is look like a simple fix, why is it delayed for so long?

[tianon]

Just for completeness, this is also filed over at moby/moby#35777 (not sure if one or the other should be closed?)

[Rickkwa]

As a workaround on Centos with iptables-services installed:

I have the following configuration in /etc/systemd/system/docker.service.d/docker.conf which flushes the iptables every time after restarting the docker daemon.

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd
ExecStartPost=
ExecStartPost=/usr/bin/systemctl reload iptables

[davecb]

We have this still showing up in

$ sudo docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:23:03 2018
 OS/Arch:           linux/amd64
 Experimental:      false

If I understand this correctly, you need to decide to not insert a pair of rules, controlled by a parameter. It seems a very long time to validate and test a relatively simple "debt" issue. We're almost up to a year.

I'd suggest that it is important, even if not urgent, and deserves attention as soon as time permits.

[bbailey1024]

Same issue. IPTables is managed by a separate process in our environment and the DOCKER-USER chain persists with iptables set to false.

docker version
Client:
 Version:           18.09.0-ce
 API version:       1.39
 Go version:        go1.11.2
 Git commit:        4d60db472b
 Built:             Fri Nov  9 00:05:34 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.0-ce
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11.2
  Git commit:       4d60db472b
  Built:            Fri Nov  9 00:05:11 2018
  OS/Arch:          linux/amd64
  Experimental:     false

[elboulangero]

This was also reported in the debian bug reports, and is now a blocker for the buster release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903635