NOTE: if you respond to this message please 'reply-all'.
I'd like to discuss firewalld on atomic host. Recently I was trying to figure out the best way to explain to other users how to set firewall rules on atomic host.
Usually I would say add your rules and then iptables-save, but on Atomic Host docker has added it's firewall rules in there dynamically so if you iptables-save you'll get a bunch of stuff that you don't want in your static configuration.
There are ways around this; manually create your config file, or use iptables-save and then rip the docker stuff out. Either way it's a bit of a pain. I think firewalld would make this easier on the user. Not sure of the pro/con ratio though.
Thoughts? Dusty
On Fri, Apr 21, 2017 at 10:16 AM, Dusty Mabe dusty@dustymabe.com wrote:
NOTE: if you respond to this message please 'reply-all'.
I'd like to discuss firewalld on atomic host. Recently I was trying to figure out the best way to explain to other users how to set firewall rules on atomic host.
Usually I would say add your rules and then iptables-save, but on Atomic Host docker has added it's firewall rules in there dynamically so if you iptables-save you'll get a bunch of stuff that you don't want in your static configuration.
There are ways around this; manually create your config file, or use iptables-save and then rip the docker stuff out. Either way it's a bit of a pain. I think firewalld would make this easier on the user. Not sure of the pro/con ratio though.
While I can see firewalld improving the situation wrt documenting how to add/persist firewall changes for Atomic Host (especially when using moby/docker), I think there is a bigger concern with firewalld being absent. If a user is running multiple applications that modify the host firewall (docker, Kubernetes, OpenShift, etc), firewalld provides a way to make firewall modifications in a consistent and repeatable manner, where iptables does not. There is the --wait flag for iptables, however any applications/users that are interacting with iptables will need to ensure they use it consistently.
-- Jason DeTiberus
On 04/21/2017 01:42 PM, Jason DeTiberus wrote:
While I can see firewalld improving the situation wrt documenting how to add/persist firewall changes for Atomic Host (especially when using moby/docker), I think there is a bigger concern with firewalld being absent. If a user is running multiple applications that modify the host firewall (docker, Kubernetes, OpenShift, etc), firewalld provides a way to make firewall modifications in a consistent and repeatable manner, where iptables does not. There is the --wait flag for iptables, however any applications/users that are interacting with iptables will need to ensure they use it consistently.
So you are saying firewalld makes your life easier if it was available?
Thanks for the input.
Dusty
On Sun, Apr 23, 2017 at 11:33 PM, Dusty Mabe dusty@dustymabe.com wrote:
On 04/21/2017 01:42 PM, Jason DeTiberus wrote:
While I can see firewalld improving the situation wrt documenting how to
add/persist firewall changes for Atomic Host (especially when using moby/docker), I think there is a bigger concern with firewalld being absent. If a user is running multiple applications that modify the host firewall (docker, Kubernetes, OpenShift, etc), firewalld provides a way to make firewall modifications in a consistent and repeatable manner, where iptables does not. There is the --wait flag for iptables, however any applications/users that are interacting with iptables will need to ensure they use it consistently.
So you are saying firewalld makes your life easier if it was available?
Correct, The iptables-based management that is done in openshift-ansible has always been a hack that was only meant to be a stopgap until firewalld was fully supported up and down the entire stack. There are way too many edge cases that could cause issues with the create/save/restore process. We tried to limit those by using a dedicated chain for openshift-ansible rules, but having another process modify rules without using '-w' or other modifications to the firewall could inadvertently be persisted with the iptables-save.
As mentioned in another reply on the thread, layered packages would allow for firewalld to be used today, but the restart requirement adds another level of complexity that adds the potential for non-determinism to the OpenShift install process. Having both iptables and firewalld available in the base would allow for parity between AH-based and non-AH-based installs.
On Fri, Apr 21, 2017, at 10:16 AM, Dusty Mabe wrote:
NOTE: if you respond to this message please 'reply-all'.
I'd like to discuss firewalld on atomic host.
I think there here are two cases:
AH-as-Kube/OpenShift host: In this I'd turn the conversation around - do Kube/OpenShift want to depend on firewalld? This has come up before, see https://bugzilla.redhat.com/show_bug.cgi?id=1403331
Standalone/"pet" AH: I think that package layering solves this today (and other "pet" cases), and ideally we would also provide a container.
Basically I don't have a definitive answer myself, but hopefully at least the above bz link is useful.
On 04/21/2017 03:18 PM, Colin Walters wrote:
On Fri, Apr 21, 2017, at 10:16 AM, Dusty Mabe wrote:
NOTE: if you respond to this message please 'reply-all'.
I'd like to discuss firewalld on atomic host.
I think there here are two cases:
AH-as-Kube/OpenShift host: In this I'd turn the conversation around - do Kube/OpenShift want to depend on firewalld? This has come up before, see https://bugzilla.redhat.com/show_bug.cgi?id=1403331
I'm not sure about kube. One thing we could do is ship firewalld and not enable it. We don't enable iptables either (at least in our cloud images). Then k8s/openshift can use whichever one they choose, right?
Standalone/"pet" AH: I think that package layering solves this today (and other "pet" cases), and ideally we would also provide a container.
Yeah, I just don't think I can honestly recommend people reboot their instance. Once livefs is here my worries go away and we probably aren't even having this conversation.
Basically I don't have a definitive answer myself, but hopefully at least the above bz link is useful.
I think manually configuring and saving firewall rules in Atomic Host is a special case. The default build is to support orchestrated containers, and that brings potential for iptables rules automation.
On Apr 21, 2017 10:17, "Dusty Mabe" dusty@dustymabe.com wrote:
NOTE: if you respond to this message please 'reply-all'.
I'd like to discuss firewalld on atomic host. Recently I was trying to figure out the best way to explain to other users how to set firewall rules on atomic host.
Usually I would say add your rules and then iptables-save, but on Atomic Host docker has added it's firewall rules in there dynamically so if you iptables-save you'll get a bunch of stuff that you don't want in your static configuration.
There are ways around this; manually create your config file, or use iptables-save and then rip the docker stuff out. Either way it's a bit of a pain. I think firewalld would make this easier on the user. Not sure of the pro/con ratio though.
Thoughts? Dusty _______________________________________________ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-leave@lists.fedoraproject.org
On 04/21/2017 05:22 PM, Subhendu Ghosh wrote:
I think manually configuring and saving firewall rules in Atomic Host is a special case. The default build is to support orchestrated containers, and that brings potential for iptables rules automation.
Currently we don't enable a firewall in our qcow images. Would delivering both iptables and firewalld but not enabling either firewall by default alleviate your concern? This means the user only really deals with firewalld if he/she wants it.
For ISO installs the user has full control over the system so can set up/enable firewall during kickstart so I'm mostly talking about cloud pre-baked image use cases.
Dusty
On 04/21/2017 10:16 AM, Dusty Mabe wrote:
NOTE: if you respond to this message please 'reply-all'.
I'd like to discuss firewalld on atomic host. Recently I was trying to figure out the best way to explain to other users how to set firewall rules on atomic host.
Usually I would say add your rules and then iptables-save, but on Atomic Host docker has added it's firewall rules in there dynamically so if you iptables-save you'll get a bunch of stuff that you don't want in your static configuration.
There are ways around this; manually create your config file, or use iptables-save and then rip the docker stuff out. Either way it's a bit of a pain. I think firewalld would make this easier on the user. Not sure of the pro/con ratio though.
reviving this old discussion: I am proposing we add firewalld do atomic host:
cloud@lists.stg.fedoraproject.org
-
Colin Walters -
Dusty Mabe -
Jason DeTiberus -
Subhendu Ghosh