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