<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On 27 Mar 2017, at 17:05, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">> Why do we need to use firewalld?<br><span class="gmail-"></span><div>I
think that the initial trigger was the realization we're completely
lacking ipv6 handling (which requires use of another, similar tool in
ip6tables) in the current infrastructure. <br><br>Assessing the situation and reviewing the code for potential solutions led us to a couple of conclusions:<br><br></div><div>- Current flow is overly complex and should be reexamined regardless.<br></div><div>-
The naive solution would be to duplicate the current flow for
ip6tables, potentially leading to a lot of boilerplate code. I'm sure
there are more sophisticated solutions that could be implemented within
the current infrastructure, but firewalld naturally came up as it allows
us to handle both ipv4 and ipv6 via a single entity.<br></div><div>- As
many of the services are already statically provided by either
firewalld or 3rd party packages, we'll be able to merely pass names of
services instead of complete rule sets.<br></div><div>- el7 is shipped with and makes use of firewalld by default.<br><br></div><div><span class="gmail-">> What is the role of the central management in this regard?<br></span>I'd like its role to be as insignificant as possible.<span class="gmail-"><br><br>> -- Does it need to manage firewalls per host in detail? (are we acting as a firewall management system?)<br></span></div><div>No.
Ansible was recently brought up as a solution/replacement to custom
rules/service deployment, and other than that, there is no justification
to having central management. The hosts have the required information
to determine which services/rules should be enabled on them (via either
vdsm or otopi)<br><br></div><span class="gmail-"><div>> -- Does it need to apply a firewall template configuration to all the hosts? (all being identical)<br>> -- Does it need to specify what services it wants the host to run and mention if the whole setup should be harden or not?<br></div></span><div>If
we do decide to keep Engine's involvement, it should be as minimal as
possible. Names of required services should be provided and that's it,
in my opinion (and even that sounds wasteful).<span class="gmail-"><br><br>> As far as I know, firewalld and
iptables can co-exist, therefore, I do not see the need to 'upgrade' or
perform a hard replacement.<br>> It can be done as an option (firewall-type: iptables/firewalld).<br>> On upgrade it continues with the 'old' definition and on new created host the default can be firewalld.<br>>
Is someone will explicitly want to change it from one to the other, we
could go with remove/add approach to make things simpler.<br></span></div><div>firewalld doesn't play well with iptables' service. Enabling firewalld disables iptables' service and flushes its rules. <br></div></div></div></blockquote><div><br></div>Understood, good to know.<div>But still, this approach will work fine, we do the same with linux/ovs bridge options. Add an option to choose the firewall type. Support both at phase 1, allowing to change the type and at phase 2 deprecate the iptables type.</div><div><br><blockquote type="cite"><div><div dir="ltr"><span class="gmail-"><div><br>> I
personally like the distributed approach, where the upper management
layer passes what it wants to the lower layers with minimum information.
Letting the lower levels<br>> do the explicit work and figure out what they need to do.<br>> If
that was the original approach, Engine would have not 'care' what type
of firewall you use down at the host, you could even use a custom
firewall, an NFV firewall solution<br>> or anything that may pop up in the future.<br><div>> Engine would have just said: I want libvirt, vdsm, ssh, etc... services opened (for access from ...).<br></div>> Custom
settings? That implies we manage firewalls. So either let the user add
their special stuff on the hosts or provide them with a proper firewall
management interface.<br></div></span>Agreed. I'll go even further
and write that Engine shouldn't even state the services hosts require; a
host should be self aware of the services it needs to use based on the
relevant configuration (e.g. if gluster is supported in the cluster,
enable gluster service)</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 26, 2017 at 4:47 PM, Edward Haas <span dir="ltr"><<a href="mailto:ehaas@redhat.com" target="_blank">ehaas@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><br>I may be too naive, but it all sounds too complex to me.<br>Is there any reference to the use cases of the firewall configuration?<br><br></div><div>Few questions:<br></div>- Why do we need to use firewalld?<br></div>- What is the role of the central management in this regard?<br>-- Does it need to manage firewalls per host in detail? (are we acting as a firewall management system?)<br>-- Does it need to apply a firewall template configuration to all the hosts? (all being identical)<br></div>-- Does it need to specify what services it wants the host to run and mention if the whole setup should be harden or not?<br><br></div>As far as I know, firewalld and iptables can co-exist, therefore, I do not see the need to 'upgrade' or perform a hard replacement.<br></div>It can be done as an option (firewall-type: iptables/firewalld).<br>On upgrade it continues with the 'old' definition and on new created host the default can be firewalld.<br></div>Is someone will explicitly want to change it from one to the other, we could go with remove/add approach to make things simpler.<br><br></div>I personally like the distributed approach, where the upper management layer passes what it wants to the lower layers with minimum information. Letting the lower levels<br></div>do the explicit work and figure out what they need to do.<br></div>If that was the original approach, Engine would have not 'care' what type of firewall you use down at the host, you could even use a custom firewall, an NFV firewall solution<br></div>or anything that may pop up in the future.<br></div><div>Engine would have just said: I want libvirt, vdsm, ssh, etc... services opened (for access from ...).<br></div><div>Custom settings? That implies we manage firewalls. So either let the user add their special stuff on the hosts or provide them with a proper firewall management interface.<br></div><div><br></div>Thanks,<br></div>Edy.<br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><span>On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali <<a href="mailto:oourfali@redhat.com" target="_blank">oourfali@redhat.com</a>> wrote:<br>
><br>
><br>
> On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com" target="_blank">lgoldber@redhat.com</a>> wrote:<br>
>><br>
>> Hey Oved,<br>
>><br>
>> I don't think completely moving away from iptables is foreseeable at this<br>
>> point, but I could be of course wrong. Either way, upgrading still needs to<br>
>> be thought of.<br>
>><br>
><br>
> I see.<br>
><br>
>><br>
>> By stating that the current infrastructure is complex, I was referring to<br>
>> the entire chain of storing rules in the database, fetching them using a<br>
>> dedicated deployment class consisting of include/exclude logic, sending them<br>
>> over, unpacking, deploying...<br>
>><br>
>> This procedure involves a lot of code that could be made redundant if the<br>
>> required logic is present in the host, which to me seems favorable. It of<br>
>> course entails other potential difficulties, primarily in the form of custom<br>
>> services.<br>
>><br>
>> I don't think otopi's firewalld plugin is any more complex than the<br>
>> potential code that will have to be written in vdsm-tool, however it<br>
>> currently expects the data generated by aforementioned chain. The hybrid<br>
>> approach briefly touches on simplifying Engine's involvement while retaining<br>
>> use of otopi's plugin.<br>
>><br>
><br>
> Okay. I think that writing a new plugin for firewalld is indeed a good<br>
> option, whether you "refactor" the engine side or not.<br>
<br>
</span>otopi already has a 'firewalld' plugin. It's already in use, at least<br>
by engine-setup, so we should be a bit careful if we want to change it.<br>
Not preventing/objecting anything, just mentioning.<br>
<br>
This plugin's interface currently only takes XML-content as input.<br>
It has no place for configuring existing firewalld services presumably<br>
already provided elsewhere (by firewalld itself or 3rd party packages,<br>
such as vdsm). So if we go that route we probably want to extend this<br>
interface to allow passing service names and rely on them being defined<br>
elsewhere.<br>
<br>
A related issue is that for engine-setup, the _input_ is currently<br>
firewalld xml content, and if users choose to configure 'iptables',<br>
this is parsed to generate iptables rules. This is currently an engine-setup<br>
issue only, but will affect also host deploy flow if we decided to<br>
allow passing service names (without their xml content) and still keep<br>
compatibility to current state and allow configuring iptables on the<br>
host. We'll then be there in the same situation we are at with engine-setup.<br>
See also <a href="https://bugzilla.redhat.com/1432354" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/14<wbr>32354</a> . An alternative is obviously<br>
deciding to remove iptables support and support only firewalld, but this<br>
is a rather radical change for users, imo.<br>
<br>
See also this for some of the existing behavior of engine-setup:<br>
<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1024707#c9" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1024707#c9</a><br>
<br>
IMO we first need to decide what we want, then how to do that. IMO the<br>
questions we have re "what we want" are, more-or-less:<br>
<br>
1. Do we want to support in some version X both iptables and firewalld, or<br>
is it ok to stop support for iptables and support only firewalld without<br>
overlap? If so, do we handle upgrades, and how?<br>
<br>
2. Do we want to support custom firewalld xml to be configured on the<br>
host by us? Or is it ok to only support choosing among existing services,<br>
which will need to be added to the host using other means (packaged by<br>
firewalld, packaged by 3rd parties, added manually by users)?<br>
<br>
3. Opposite of (2.): Do we want to support firewalld services that are<br>
added to the host using other means (see there)? Obviously we do, but:<br>
If we do, do we still want to support also iptables (see (1.))? And if<br>
so, what do we want to then happen?<br>
<br>
(2.) and (3.) are not conflicting, each needs its own answer.<br>
<br>
My (thoughts about) answers:<br>
<br>
1. If done well enough, and considerably simplifies things, I think it's<br>
ok to jump directly from "only iptables" to "only firewalld", but then<br>
we should announce this ahead of time to give users time to plan/prepare.<br>
If it's not too costly, I'd prefer to support both for the foreseeable<br>
future, though.<br>
<br>
2. Latter option here is problematic, if we need/want to allow<br>
customizing services during deploy. E.g. suppose that one day we want<br>
to make the vdsm port configurable. It will be nice if this can be done<br>
by only changing things on the engine, without having to distribute<br>
changes (conf and/or packages) to all hosts before host-deploy.<br>
I'd say we can go a long way here by having a strict requirement from<br>
all services that we need/want on hosts to have official IANA-registered<br>
port numbers - then, it's imo much easier to tell users "If you want to<br>
change the port for service X, you have to (long list of complex actions<br>
goes here)". Currently, where services are not registered, we risk<br>
conflicts with existing services, requiring the user to change ports -<br>
and so we can't make this process too difficult. No idea how important<br>
this is in practice.<br>
<br>
3. Not sure :-( I'd say that if we want to support both iptables and<br>
firewalld together, and support both "xml in engine" and "xml in host",<br>
then it might be ok if the custom rules/services will not automatically<br>
apply to both iptables and firewalld. Meaning - you can set both custom<br>
iptables rules and firewalld services, but it's up to you to make sure<br>
they actually do the same thing if that's important to you.<br>
<br>
Bottom line: I think we should summarize the open questions in a way<br>
that will make it clear to users how each answer will affect them, and<br>
ask what they think. Leon already started doing this [1], I only saw<br>
one reply. Perhaps this means that users do not care that much, and<br>
expect us to just decide and tell them what we decided (and always to<br>
keep the option to disable this feature, as is possible today, and do<br>
this themselves, if our choice of solution does not fit their needs).<br>
<br>
I know this is way too loooong, sorry. Feel free to ignore, but then<br>
please ask simpler questions if you want shorter answers :-)<br>
<br>
[1] <a href="http://lists.ovirt.org/pipermail/users/2017-March/080600.html" rel="noreferrer" target="_blank">http://lists.ovirt.org/piperma<wbr>il/users/2017-March/080600.<wbr>html</a><br>
<div class="m_7457438430304499453HOEnZb"><div class="m_7457438430304499453h5"><br>
><br>
>><br>
>><br>
>><br>
>> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <<a href="mailto:oourfali@redhat.com" target="_blank">oourfali@redhat.com</a>> wrote:<br>
>>><br>
>>> top-posting:<br>
>>> You need to also consider how upgrade will be handled, right?<br>
>>> Or iptables will still remain supported?<br>
>>><br>
>>> Also, see some comments inline.<br>
>>><br>
>>> Regards,<br>
>>> Oved<br>
>>><br>
>>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com" target="_blank">lgoldber@redhat.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>><br>
>>>> Hey,<br>
>>>><br>
>>>> We're looking to migrate from iptables to firewalld. We came up with a<br>
>>>> couple of possible approaches we'd like opinions on. I'll list the options<br>
>>>> first, and will<br>
>>>><br>
>>>> 1) Replicate existing flow:<br>
>>>><br>
>>>> As of date, iptable rules are inserted in the database via SQL config<br>
>>>> files. During host deployment, VdsDeployIptablesUnit adds the required rules<br>
>>>> (based on cluster/firewall configuration) to the deployment configuration,<br>
>>>> en route to being deployed on the host via otopi and its iptables plugin.<br>
>>>><br>
>>>> Pros:<br>
>>>><br>
>>>> - Reuse of existing infrastructure.<br>
>>>><br>
>>>> Cons:<br>
>>>><br>
>>>> - Current infrastructure is overly complex...<br>
>>><br>
>>><br>
>>> Can you elaborate?<br>
>>> I'm not an otopi expert, but I think that otopi plugins shouldn't be more<br>
>>> complex than what you describe in section #2, and the plugins were meant in<br>
>>> order to handle such cases.<br>
>>><br>
>>>> - Many of the required services are provided by firewalld. Rewriting<br>
>>>> them is wasteful; specifying them (instead of providing actual service .xml<br>
>>>> content) will require adaptations on both (engine/host) sides. More on that<br>
>>>> later.<br>
>>>><br>
>>>><br>
>>>> 2) Host side based configuration:<br>
>>>><br>
>>>> Essentially, all the required logic (aforementioned cluster/firewall<br>
>>>> configuration) to determine if/how firewalld should be deployed could be<br>
>>>> passed on to the host via ohd. Vdsm could take on the responsibility of<br>
>>>> examining the relevant configuration, and then creating and/or adding the<br>
>>>> required services (using vdsm.conf and vdsm-tool).<br>
>>>><br>
>>><br>
>>> So here you replace the otopi plugin with relevant vdsm-tool code, and<br>
>>> the question is why is that better?<br>
>>><br>
>>>><br>
>>>> Pros:<br>
>>>><br>
>>>> - Engine side involvement is greatly diminished.<br>
>>>> - Simple(r).<br>
>>>><br>
>>>> Cons:<br>
>>>><br>
>>>> - Custom services/rules capabilities will have to be rethought and<br>
>>>> re-implemented (current infrastructure supports custom iptables rules by<br>
>>>> being specified in the SQL config file).<br>
>>>><br>
>>>><br>
>>>> 3) Some other hybrid approach:<br>
>>>><br>
>>>> If we're able to guarantee all the required firewalld services are<br>
>>>> statically provided one way or the other, the current procedure could be<br>
>>>> replicated and be made more simpler. Instead of providing xml content in the<br>
>>>> form of strings, service names could be supplied. The responsibility of<br>
>>>> actual service deployment becomes easier, and could be left to otopi (with<br>
>>>> the appropriate modifications) or switched over to vdsm.<br>
>>>><br>
>>>> --<br>
>>>><br>
>>>> Regardless, usage of statically provided vs. dynamically created<br>
>>>> services remains an open question. I think we'd like to avoid implementing<br>
>>>> logic that ask whether some service is provided (and then write it if it<br>
>>>> isn't...), and so choosing between the dynamic and static approaches is also<br>
>>>> needed. Using the static approach, guaranteeing all services are provided<br>
>>>> will be required.<br>
>>>><br>
>>>> I do believe guaranteeing the presence of all required services is worth<br>
>>>> it, however custom services aren't going to be naively compatible, and we'll<br>
>>>> still have to use similar mechanism as described in #1 (service string -><br>
>>>> .xml -> addition of service name to active zone).<br>
>>>><br>
>>>><br>
>>>> Your thoughts are welcome.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Leon<br>
>>>><br>
>>><br>
>><br>
><br>
<br>
<br>
<br>
</div></div></div></div><span class="HOEnZb"><font color="#888888"><span class="m_7457438430304499453HOEnZb"><font color="#888888">--<br>
Didi<br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
</font></span></font></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br></div>
</div></blockquote></div></body></html>