from ben breard on list: if we include it we would want to clean up the absurd default zones & policies and have something relevant for AH out of the box

See https://bugzilla.redhat.com/show_bug.cgi?id=876669 -- there's a conceptual design problem overall with what zones represent.

I was originally not a fan of adding in firewalld but have come around after some conversations. The downside is the amount of space it may add to the ISO but I have a feeling it's not as large of an addition as I think.

+1 to adding firewalld

As a user of Atomic, I would like to see firewalld included for various reasons.

1. The inclusion of firewalld with only port 22 open would limit access to services unless explicitly granted, as per best practises and required by many security certifications, among them the certificates issued for companies by the German "Federal Office for Information Security". While it is possible to achieve those certificates with a proper external firewall concept, the lack of firewalld makes the certification process a lot harder.
2. While iptables are of course present on Atomic, fiddling with them is a lot more error-prone than with firewalld. This adds to complexity of administration, and complexity inevitably will cause mistakes which in a worst case scenario will lead to security incidents which could have been avoided.
3. While the classical deployment scenario for Atomic is in a well protected, properly tiered environment, Atomic may well be used on providers such as Digital Ocean. It would be good if a user had the peace of mind that regardless what he or she deploys, it can be hardened first (via ssh tunnel for example) and reachable only after the service was explicitly opened to the public by means of a firewall. And all of that without relying on external services such as <InsertCloudProvidersNameHere> firewall service

See also https://bugzilla.redhat.com/show_bug.cgi?id=1403331

One detail right now is that since we include docker and start it by default, and today docker dynamically detects presence of firewalld, it means installing firewalld after the fact (whether via a container or package layering) requires restarting docker. So that's an argument to include it by default.

Though there's a whole other question of whether or not we start it by default...

Thanks @mwmahlberg for the input. So this ticket mainly touches on including firewalld in the host. We haven't really discussed whether enabling it by default is something that we desire to do. Most cloud images do not have a firewall enabled by default because the cloud provider typically provides some sort of higher level security groups like firewall. As for normal installs with the ISO image, I'm open to having that default to enable a firewall by default, but it currently also does not do that.

OpenShift doesn't like firewalld according to clayton and @vbatts.

OpenShift doesn't like firewalld according to clayton and @vbatts.

That's interesting ... the reason firewalld ever came up was because of a want from the Openshift guys. We'll have to find out if things may have changed...

Though there's a whole other question of whether or not we start it by default...

It'd be super-super awesome if it would be dbus or socket activated.

OpenShift Online Operations would really like firewalld to be included in atomic host.

We don't currently use firewalld, but we'd like to move to it sometime in the future.

The thing we like most about firewalld is that since it has an API to manage persistent firewall rules, it integrates very well into config management.

For instance, we use Ansible for config management and there is a firewalld Ansible module.

There is also an iptables Ansible module, but since there isn't an iptables API to manage persistent firewall rules, this Ansible module also doesn't handle persistent iptable rules.

OpenShift doesn't like firewalld according to clayton and @vbatts.

Firewalld would be the preferred firewall management tool for OpenShift if it were available on atomic host. OpenShift needs to be kept aware of firewall changes so that it can ensure that all the required rules are there. When using firewalld openshift becomes aware of changes and can immediately reconcile the rules, without firewalld it has to resync everything periodically which leaves a windows of brokenness and I believe that syncing the rules is more costly than necessary.

@eparis @dcbw @danw -- was there some recent change to our disposition on preference for firewalld?

I'm not aware of any change to our disposition on firewalld. I think the "OpenShift doesn't like firewalld" comment is probably the result of a bad game of telephone that started with "OpenShift doesn't want to require firewalld because it's not available on Atomic"

"not available" hasn't been correct for some time; rpm-ostree install firewalld works on current RHELAH and is in full support since RHELAH 7.4.0.

• good for new users :white_check_mark:
• good for openshift/kube :white_check_mark:
• opportunity to improve default policies :white_check_mark:
• increased size on disk :x:

Seems like an overall win to me; +1 to including it

Two outstanding things:

Other Packages

It was noted by @walters that there may be other packages required for firewalld to be helpful for openshift-ansible.

According to ansible the only requirement is firewalld >= 0.2.11, but this should be checked.

firewalld On By Default

There is a question over if firewalld should be on or off by default.

I'd like to see a total in MB and list of dependencies we'll be adding for this. It's probably not significant, but we should check it before making a decision.

I'd like to see a total in MB and list of dependencies we'll be adding for this. It's probably not significant, but we should check it before making a decision.

[vagrant@vanilla-f26atomic ~]$ sudo microdnf install firewalld 
Downloading metadata...
Downloading metadata...
Package                                           Repository Size
Installing:                                                    
 ebtables-2.0.10-22.fc26.x86_64                   fedora     128.0 kB
 firewalld-0.4.4.5-1.fc26.noarch                  fedora     489.3 kB
 firewalld-filesystem-0.4.4.5-1.fc26.noarch       fedora      72.1 kB
 ipset-6.29-3.fc26.x86_64                         fedora      46.6 kB
 ipset-libs-6.29-3.fc26.x86_64                    fedora      59.0 kB
 python3-firewall-0.4.4.5-1.fc26.noarch           fedora     368.0 kB

So tiny.

Also, we get ebtables, which eliminates a layering dependancy for Kubelet. So win-win.

FYI: This has been pulled into our current sprint and @dustymabe has added it to his plate.

related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1403331

for completeness, there is also a firewalld system container work going on here:

https://github.com/projectatomic/atomic-system-containers/pull/150

ok, new info. firewalld will pull in the python3-firewall package which enables ansible support for when executing using python3. Do we want to also include python-firewall (py2 ansible support). Here are the extra packages we get if we add the python-firewall package:

 dbus-python-1.2.4-8.fc27.x86_64             fedora    132.0 kB
 python-firewall-0.4.4.5-3.fc27.noarch       fedora    358.1 kB
 python-slip-0.6.4-7.fc27.noarch             fedora     36.9 kB
 python-slip-dbus-0.6.4-7.fc27.noarch        fedora     36.9 kB
 python2-decorator-4.0.11-3.fc27.noarch      fedora     25.6 kB
 python2-gobject-base-3.26.1-1.fc27.x86_64   updates   308.9 kB

Feels like we need to start somehow deprecating Ansible+Python2+AH slowly? Maybe we should make python2 do a sleep(10) on startup or something.

Anyways I think my vote is: let's not add it for now and see if anyone complains?

Anyways I think my vote is: let's not add it for now and see if anyone complains?

ok, yeah I think we already recommend that openshift-ansible users use python3 as the interpreter so we shouldn't lose them there.

ok, yeah I think we already recommend that openshift-ansible users use python3 as the interpreter so we shouldn't lose them there.

That's correct. At this point openshift-ansible should be 100% Python 3 compliant. @gscrivano and I did quite a bit of work last year updating modules to ensure they worked in legacy and 3.

/cc @sdodson

/me makes a mental note that we'll have to start verifying that 'atomic-host-tests' works with Python3

This landed in atomic host 27.61. See blog post about it here.