Our security system scan flagged the IP forwarding as security vulnerability in the host OS running docker containers. After disabling IP forwarding in the host OS, the application running in the docker container is not reachable.
In the latest docker ce versions, the docker daemon automatically enable IP forwarding on start/restart.
I would like to understand why docker daemon enable IP forwarding in the host OS automatically.
Is there a way to restrict the docker daemon not to enable IP forwarding by default? Without IP forwarding is there a way to configure connectivity between container network and host network?(using host network in docker containers is not possible in our application architecture)
IP forwarding is required for Docker bridge networks. which is the default driver. It doesn’t require a router or available LAN network or dedicated VLAN to have container IPs. If you disable IP forwarding, your host can’t act like a gateway, but when you use bridge networks, your host is always the gateway and it gets an IP address in the bridge network. Your outgoing network traffic would not work and you could not forward port from your host to the container IPs, so you would not be able to publish any ports.
I guess your security system scan glagged this feature because if it is not handled carefully, your machine could forward any request to anywhere and someone would access an IP which is available only from your machine.
Docker handles iptables rules and allows forwarding to and from containers when it is necessary and safe. If your default iptables forward policy is ACCEPT and you have ip forwarding allowed as well, someone could set your machine/server as gateway and allow container IPs on the docker bridge remotely. So ip forwarding itself is not necessarily a security risk, but it can be combined with other configuration mistakes.
If you can’t adjust your security scan config to accept ip forwarding if related configurations are done properly, you can use MacVLAN instead of the default bridge driver
I don’t remember a release version from the last 10 years that didn’t masquerade the outgoing container traffic with snat for bridge networks. Of course, this covers that response packages to outgoing request messages are passed back to a container. Incoming container request always required the container port to be published on the host port.