[Freeipa-devel] Ipa-server-install Firewall Support

[Martin Kosek]

On 04/04/2014 09:04 AM, Justin Brown wrote:
> Thanks for the feedback Martin.
> 
>> I would actually do it the opposite way and open the ports after the FreeIPA server is fully configured. After all, I do not think we want to open the ports when the server is just half-configured and for example some ACIs are missing.
> 
> My thinking was that nothing would be listening on these ports if the
> install doesn't succeed, but there's really necessity to modify the
> firewall configuration early. (All of the internal install
> communication will be over a local interface (to netfilter) and
> unblock anyways. I don't have any problem in delaying firewall
> configuration to the end of install.

If ipa-server-install does succeed without configuring the firewalld, then we
will indeed have no other option than to do it early.

I am  thinking that we may want to put all the firewalld configuration in
ipaserver/install/firewalldinstance.py,
and then make the firewalld configuration the actual step of the installation.
Something like:

...
Configuring Firewall (firewalld)
  [1/2]: looking up the right zone
  [2/2]: allowing ports
Done configuring Firewall (firewalld).
...

The Service class derived object can be really simple, we would just reuse the
functionality it already has + let us properly hook into it in
ipa-{server,replica}-install and the uninstallation.

It would also make it easier to split this functionality to
freeipa-server-firewalld if we chose to in a future.

>> We print list of ports that FreeIPA uses at the end of ipa-server-install process. I would report firewalld/iptables related information there. (We for example also create here example BIND zone content and pass it to user, it may make sense to have this around this location).
> 
> Agreed and noted.
> 
>> Hm, I would personally prefer to avoid complicating the feature and start with something easy to configure and straightforward. We can always extend it if we see an interest. In general, ipa-server-install does the basic, functional and recommended configuration - fine tuning is left for the administrator to continue after that. But I will leave that up to you and other developers.
> 
>> I think it would be better to have them all in a single XML file though (like freeipa.xml), less chance of name collisions and we would have all ports in one place.
> 
>> Not sure about the names, but it may be good idea to prefix the port names with "freeipa", i.e. "freeipa-ldap", "freeipa-ldaps", "freeipa-kerberos" to avoid collisions.
> 
> My thinking here was that it is quite cumbersome to restrict a
> FirewallD service to specific networks (i.e. taking a service assigned
> to a zone and replacing it with rich rules that do allow source
> restrictions). I'm not sure how people actually use FreeIPA outside my
> use-case, but if users are unable to restrict server-ipa-install
> firewall configuration to specific networks, they'll most likely need
> to depend on an external firewall (e.g. Amazon's EC2 firewall). On the
> other hand, I totally agree with your apprehension to add more options
> to ipa-server-install. I'll prepare two patch sets that just add the
> service (without source restrictions) and another that allows network
> restrictions. That will make it easier for the project to choose the
> correct solution and have an implementation for either solution.

Ok, though I would not make this 2 paralel patch sets, it may be easier for you
(and reviewers) to have patches adding basic Firewalld support and then a patch
on top of that adding the zone restriction options.

> As to the specific service name, FirewallD already has most service
> definitions that FreeIPA needs (http(s), kerberos, kpasswd, ntp,
> etc.). I would imagine that these services will always be available,
> but I'm going to inquire with the FirewallD project to make sure.

Ok, a feedback from FirewallD upstream may be valuable

> If
> we are sure those services will always be there, I would greatly
> prefer to use those built-in services as much as possible. For
> example, FirewallD includes a ldap service, and I don't think there's
> a good reason to include a freeipa-ldap that covers the same ports.

Makes sense.

> 
>> Ok. We also should not crash if the directory is not available. There are some recommendations about the XML contents in a Bugzilla comment:
> 
> Yep. I'm always vigilant to catch exceptions.
> 
> Thanks,
> Justin

Thanks,
Martin