<div dir="ltr">Hello, <div><br></div><div>A few additions for/against firewalld, linked to ansible's firewalld module: <a href="http://docs.ansible.com/ansible/latest/firewalld_module.html">http://docs.ansible.com/ansible/latest/firewalld_module.html</a></div><div><br></div><div>+:<div>The module is built-in, so no need to ship it. It provides idempotency, and is easy to use.</div><div><br></div><div>-:</div>The module is: "Not tested on any Debian based system.<br>Requires the python2 bindings of firewalld, which may not be installed by default if the distribution switched to python 3".</div><div><br></div><div>My take:</div><div><br></div><div>For ppl who aren't iptables experts, firewalld module brings a lot of readability.</div><div>If we are doing the tasks equivalent with iptables, the readability will be brought in by variables (I mean variables to list ports_to_open are fairly easy to understand).</div><div><br></div><div>I am myself preferring to always use modules, and so, use the firewalld module (because it's already upstream, less tasks and therefore less error prone).</div><div>However, that would mean that we improve the module itself to grant what we need: Real ubuntu and python3 support.</div><div>Maybe it's a crusade that nobody wants to partake in, and using iptables would mean a path to least resistance, therefore easier to ship.</div><div>On top of it, if it's more a hassle to use the module due to complex rules (do we even need that?), I'd understand the move to iptables management. Is there already a role to handle this?</div><div><br></div><div>Best regards,</div><div>JP</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 26, 2017 at 3:59 PM, Major Hayden <span dir="ltr"><<a href="mailto:major@mhtx.net" target="_blank">major@mhtx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Hey there,<br>
<br>
I'm working through some drafts of a spec[0] (rendered[1]) that aims to deploy software firewalls within an OpenStack-Ansible deployment. The goal is to increase security by restricting lateral movement.<br>
<br>
One of the questions that was raised was the method for managing firewall rules. The spec lays out a plan for firewalld since it is available in the supported operating systems (Ubuntu 16.04, CentOS 7, OpenSUSE 42.x) and it allows us to control IPv4/IPv6 rules in the same place.<br>
<br>
However, Logan makes a good point about using a jinja template to write firewall rules to a file and load that via normal iptables service mechanisms. I definitely see merit to that approach, too.<br>
<br>
I'd really like feedback from developers/operators of OpenStack-Ansible to determine the best method to proceed. Here's what I've come up with so far:<br>
<br>
firewalld advantages<br>
- --------------------<br>
1) Available in all distributions we support<br>
2) Provides simple commands to interface with firewall rules<br>
3) Manages IPv4/IPv6 iptables rules at the same time<br>
<br>
firewalld disadvantages<br>
- -----------------------<br>
1) Different distributions have different base rule sets<br>
2) Medium/High complexity rules require --direct, which is like using iptables anyway<br>
3) It's another daemon to manage/monitor<br>
4) We wouldn't be able to use firewalld's "zones" very heavily<br>
5) Saving/restoring iptables rules is battle-tested already<br>
<br>
<br>
[0] <a href="https://review.openstack.org/#/c/479415/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/479415/</a><br>
[1] <a href="http://docs-draft.openstack.org/15/479415/5/check/gate-openstack-ansible-specs-docs-ubuntu-xenial/6a50e01//doc/build/html/specs/pike/software-firewall.html" rel="noreferrer" target="_blank">http://docs-draft.openstack.<wbr>org/15/479415/5/check/gate-<wbr>openstack-ansible-specs-docs-<wbr>ubuntu-xenial/6a50e01//doc/<wbr>build/html/specs/pike/<wbr>software-firewall.html</a><br>
<br>
- --<br>
Major Hayden<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQIzBAEBCAAdFiEEG/<wbr>mSZJWWADNpjCUrc3BR4MEBH7EFAll4<wbr>rkwACgkQc3BR4MEB<br>
H7G3ThAAkYfAGPThoaLK+a+<wbr>xSZjQrrDYo3T2Q8h/<wbr>nCVdSbXU1npfv0wnIUcpezH7<br>
a2bq4tSOX53tupUtvtMXK1VzSh5zQb<wbr>ohewfndmAOpwH8yNJ6UdnBjTfNXbs1<wbr>WU05<br>
ke6X/<wbr>RIvkNEKO4q5RvO3hbgKFKtLFdDVWRa<wbr>7m6ORM2UaN2QXRrr85Cs0GrS0wWJq<br>
XDLVf5277VPXiobntUkdSdVAHfPX0Q<wbr>ULMUBxSbnhAjGhLWfZnGiyInntHAu0<wbr>rGqj<br>
xhkZNT3wuEMmorbIfUkY1NhjWJyy5L<wbr>yjCar+hpJKRz/<wbr>pNlFiOiF36Ps4PLNBW06P<br>
IwL3IbTkOwI6KPffFBqmMYb2AHsbqp<wbr>nwxjBjoUQv1YvW55IZn3EliUY0t05J<wbr>BFZ0<br>
N4EDNplyX9UhEQdFQrKHkOjCzADuuI<wbr>/<wbr>nnngfsZiCziiU068mRYIp4S3phj6Qi<wbr>OZP<br>
bHdjQDUx3X7rk1s6i7SdLPxPYNPxEs<wbr>6wipXzofjB4STwDYqFKmpSNOTecLVN<wbr>64PE<br>
H1bmt/<wbr>lOfSpl05jjwhk8Jaxd0RgMAM2a7pA7<wbr>nsTpFqRG4v7VaucewGaCRypCvAUD<br>
JiuQ+<wbr>RYCNifEBb8nX6lx8TnJLCzaFK4xZuE<wbr>dpBqGCwKaXRYUqdS+W2bRPqRY6EmF<br>
5jYN1d2U0rxyYmQ1cH921VQPhA8K14<wbr>2FoUgq+oqiaH/8cqeWr9o=<br>
=lwtm<br>
-----END PGP SIGNATURE-----<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div>