On 06/04/2016 17:17, Rich Megginson wrote: > On 04/06/2016 02:55 AM, Hayes, Graham wrote: >> On 06/04/16 03:09, Adam Young wrote: >>> On 04/05/2016 08:02 AM, Hayes, Graham wrote: >>>> On 02/04/2016 22:33, Adam Young wrote: >>>>> I finally have enough understanding of what is going on with Tripleo to >>>>> reasonably discuss how to implement solutions for some of the main >>>>> security needs of a deployment. >>>>> >>>>> >>>>> FreeIPA is an identity management solution that can provide support for: >>>>> >>>>> 1. TLS on all network communications: >>>>> A. HTTPS for web services >>>>> B. TLS for the message bus >>>>> C. TLS for communication with the Database. >>>>> 2. Identity for all Actors in the system: >>>>> A. API services >>>>> B. Message producers and consumers >>>>> C. Database consumers >>>>> D. Keystone service users >>>>> 3. Secure DNS DNSSEC >>>>> 4. Federation Support >>>>> 5. SSH Access control to Hosts for both undercloud and overcloud >>>>> 6. SUDO management >>>>> 7. Single Sign On for Applications running in the overcloud. >>>>> >>>>> >>>>> The main pieces of FreeIPA are >>>>> 1. LDAP (the 389 Directory Server) >>>>> 2. Kerberos >>>>> 3. DNS (BIND) >>>>> 4. Certificate Authority (CA) server (Dogtag) >>>>> 5. WebUI/Web Service Management Interface (HTTPD) >>>>> >>>> <snip> >>>> >>>>> There are a couple ongoing efforts that will tie in with this: >>>>> >>>>> 1. Designate should be able to use the DNS from FreeIPA. That was the >>>>> original implementation. >>>> Designate cannot use FreeIPA - we haven't had a driver for it since >>>> Kilo. >>>> >>>> There have been various efforts since to support FreeIPA, but it >>>> requires that it is the point of truth for DNS information, as does >>>> Designate. >>>> >>>> If FreeIPA supported the traditional Notify and Zone Transfer mechanisms >>>> then we would be fine, but unfortunately it does not. >>>> >>>> [1] Actually points out that the goal of FreeIPA's DNS integration >>>> "... is NOT to provide general-purpose DNS server. Features beyond >>>> easing FreeIPA deployment and maintenance are explicitly out of scope." >>>> >>>> 1 - http://www.freeipa.org/page/DNS#Goals >>> >>> Lets table that for now. No reason they should not be able to >>> interoperate somehow. >> Without work being done by FreeIPA (to enable the XFR interface on the >> bind server) or us (Designate) re-designing our DNS Driver interface >> they will not be able to inter-operate. > > It's going to be very difficult for FreeIPA to support XFR for the > "main" zone (i.e. the zone in which records are actively > updated/maintained in LDAP and kept in sync globally). It might be > possible to make it work for a child/sub zone that LDAP doesn't have to > pay much attention to, and let that zone be updated by Designate via > XFR. I suppose Designate has the same problem with AD DNS integration?
Yes, we do. The MS DNS server has support for other secondary zones that we could use - that is what we did in the pre Kilo driver. (as a disclaimer, the msdns driver is known-broken, and unless there is some resurgence of interest in it it will be deleted soon.) > If you want to discuss this more, we can take the discussion to > freeipa-us...@redhat.com Will spin up a thread there - thanks. > The ipa/nova join functionality allows new VM hosts to be automatically > registered with IPA, including the DNS records for floating IP > assignments, bypassing Designate. Ah, I did not realise there was work done on that. There was quite a bit of work done this cycle to tie nova + neutron + designate together by adding a "dns_name" to neutron ports - that is what we focused on. >> >> >>>> >>>>> 2. Juan Antonio Osorio has been working on TLS everywhere. The issue >>>>> thus far has been Certificate management. This provides a Dogtag server >>>>> for Certs. >>>>> >>>>> 3. Rob Crittenden has been working on auto-registration of virtual >>>>> machines with an Identity Provider upon launch. This gives that efforts >>>>> an IdM to use. >>>>> >>>>> 4. Keystone can make use of the Identity store for administrative users >>>>> in their own domain. >>>>> >>>>> 5. Many of the compliance audits have complained about cleartext >>>>> passwords in config files. This removes most of them. MySQL supports >>>>> X509 based authentication today, and there is Kerberos support in the >>>>> works, which should remove the last remaining cleartext Passwords. >>>>> >>>>> I mentioned Centralized SUDO and HBAC. These are both tools that may be >>>>> used by administrators if so desired on the install. I would recommend >>>>> that they be used, but there is no requirement to do so. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev