Add internal n/w bridge to firewalld docker zone#47293
Add internal n/w bridge to firewalld docker zone#47293akerouanton merged 1 commit intomoby:masterfrom
Conversation
Containers attached to an 'internal' bridge network are unable to communicate when the host is running firewalld. Non-internal bridges are added to a trusted 'docker' firewalld zone, but internal bridges were not. DOCKER-ISOLATION iptables rules are still configured for an internal network, they block traffic to/from addresses outside the network's subnet. Signed-off-by: Rob Murray <rob.murray@docker.com>
| var version iptables.IPVersion | ||
| var inDropRule, outDropRule iptRule | ||
|
|
||
| // Either add or remove the interface from the firewalld zone, if firewalld is running. |
There was a problem hiding this comment.
It seems ProgramChain is only called by the bridge driver. Do you think it'd make sense to move the calls to Add/Del methods out of the iptables package to setupIPTables (ie. setupInternalNetworkRules caller), such that we don't duplicate these in two different places?
There was a problem hiding this comment.
Yes, I don't think the firewalld calls belong with the rest of ProgramChain, and should be called separately (and once) by the bridge driver.
It looked like a bit of a mess though. And, particularly for firewalld, not well regression tested. So, I figured a minimal change would be more likely to make it into 25.0.3.
And, it's the usual problem with changing an exported package? Maybe that doesn't matter? Or, if it does, we could split ProgramChain, and make it call new functions that we use from the bridge driver?
But perhaps that should be a separate refactoring PR?
There was a problem hiding this comment.
Separate refactoring PR, please, because I already have one: #46666
There was a problem hiding this comment.
Excellent! Thanks Cory.
Fixes #47229
- What I did
Containers attached to an 'internal' bridge network are unable to communicate when the host is running firewalld.
Non-internal bridges are added to a trusted 'docker' firewalld zone, but internal bridges were not - they are now.
- How I did it
For a non-internal network, the Add/Del functions are called by
iptables.ProgramChain(multiple times per bridge). There's there's no equivalent in the iptables package for an internal network. So, this change calls them from the bridge driver, in the function that's used for create and cleanup of an internal bridge's rules.- How to verify it
Tested a local build on openSUSE, using the example in the original ticket.
Without this change, pings and curls over the internal network fail, they hit a 'reject with icmpx admin-prohibited' firewalld rule.
With the change, communication between containers works. The DOCKER-ISOLATION iptables rules are still configured for an internal network, they block traffic to/from addresses outside the network's subnet (checked by looking at counters in
iptables -nvL -t filter). The bridge still does not get an IP address, so there's no route for communication with the host. So, it is still an internal network.It should be covered by existing tests in 'integration/networking/bridge_test.go' ... but I don't think we run CI on any hosts that use firewalld?
- Description for the changelog
Include 'internal' network bridges in the 'docker' zone for firewalld, so that containers can communicate.