<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">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali <<a href="mailto:oourfali@redhat.com">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">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/<wbr>1432354</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/<wbr>show_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/<wbr>pipermail/users/2017-March/<wbr>080600.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>><br>
>><br>
>> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <<a href="mailto:oourfali@redhat.com">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">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><span class="HOEnZb"><font color="#888888">--<br>
Didi<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>
</font></span></blockquote></div><br></div>