Open Stack

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-users at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>