Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FirewallD doesn't go well with Docker #461

Open
maverick85 opened this issue Feb 14, 2019 · 3 comments

Comments

Projects
None yet
4 participants
@maverick85
Copy link

commented Feb 14, 2019

Hi everybody,

I am an avid user of CentOS which ships firewalld since long.

So I've been using Docker fairly recently and yesterday I noticed firewalld rules are completely ignored by docker/docker containers. I found this funny cause on your Home page you read:

Applications and libraries which support firewalld as a firewall management tool include:

  • NetworkManager
  • libvirt
  • docker
  • fail2ban

So basically I was setting up a server whose sole purpose is to run docker containers.
After setting things running, as I had a DB container running, I did the following:

firewall-cmd --permanent --new-zone=test-from-home && firewall-cmd --reload
firewall-cmd --permanent --zone=test-from-home --add-service=mysql
firewall-cmd --permanent --zone=test-from-home --add-source=XX.XX.XX.XX/32
firewall-cmd --reload

So then I went to testing, and I connected just fine. But then I logged in to another remote server, and I accessed the same when I totally should not.

These are outputs of my firewalld:

firewall-cmd --zone=test-from-home --list-all
test-from-home (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: XX.XX.XX.XX/32
  services: mysql
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
firewall-cmd --zone=public --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: ssh dhcpv6-client
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
[root@nd01 latest]# firewall-cmd --get-active-zones
test-from-home
  sources: XX.XX.XX.XX/32
public
  interfaces: eth0

Also, I asked a friend to test using netcat, from yet another random location, and he manages to connect too...

FirewallD doesn't play nice with Docker (or vice-versa)

Meanwhile I came across the fact that FirewallD and Docker do not play along.
According to the Docker documentation, the way to circumvent this is by disabling IPTables:

As it says from the very first stance:

On Linux, Docker manipulates iptables rules to provide network isolation. This is an implementation detail, and you should not modify the rules Docker inserts into your iptables policies.

Which wouldn't be my first resort as adviced against.

So I don't get how we go from this to firewalld friendly, but I would enjoy learning.
Anyway, this page goes on about how to fix it, and I actually took a few ideas from another blog post I came across Docker meets firewall - finally an answer and set it up.

But as firewalld gets more and more audience, I think it would be useful if someone:

a) fix where it says firewalld works with docker...
b) make firewalld play nice with docker?
maybe by adding a plugin for docker that would allow to move on the DOCKER-USER chain?

CentOS 7 minimal-install;
Docker version 18.09.2, build 6247962
@erig0

This comment has been minimized.

Copy link
Collaborator

commented Feb 19, 2019

Applications and libraries which support firewalld as a firewall management tool include

IIRC, in the case of docker this means docker will see that firewalld is in use and add it's rules through firewalld's direct interface. It's not full support, but it is some support.

maybe by adding a plugin for docker that would allow to move on the DOCKER-USER chain?

This can be done already.

# firewall-cmd --permanent --direct --add-chain ipv4 filter DOCKER-USER
# firewall-cmd --permanent --direct --add-rule ipv4 filter DOCKER-USER <priority> ...

I'm not sure what you're looking for. "play nice with docker" is a very vague request - especially as some level of "playing" already exists.

@erig0 erig0 added the needinfo label Feb 19, 2019

@jackhill

This comment has been minimized.

Copy link

commented Apr 25, 2019

I'm not sure what @maverick85 means by "play nice with docker", but for me that means that traffic to the ports that are published by docker are subject to the same filtering rules as if a service was running on a port without the docker isolation.

For example, suppose I only enable the https service in firewalld for the work zone. If I run a "native" webserver on 443, connections not associated with the work zone would be denied. However, as it stands now, if I run a webserver in docker, with -p 443:8443 to set up the port forwarding, any connection will be allowed. What I would like to happen is that only connection that would have been associated with the work zone be allowed.

From @erig0's comment and others on the Internet, it seems there is a work-around by setting up rules in the DOCKER-USER chain, but a major downside to me, is that firewalld's concept of zones is not available in the DOCKER-USER chain.

@zyv

This comment has been minimized.

Copy link

commented Apr 29, 2019

I've just stumbled upon this problem and second the comments of @jackhill and @maverick85.

On a freshly installed CentOS 7 system with firewalld and docker from system repositories, and my expectation is that the firewall rules from the public zone which are locked down by default have exactly the same effect on ports opened and forwarded from Docker containers, but with great (and unpleasant) surprise I have found out that my Jenkins instance running inside a Docker container is public instead, and now I know why.

Is there a cleaner way to solve this problem with making zone settings apply to Docker or the only way is to hack around with DOCKER-USER chain? Can one implement something suitable with Ansible firewalld module, or one is bound to firewalld CLI commands?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.