Open Stack

On 04/06/2016 10:38 AM, Hayes, Graham wrote:
> 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.

The work that was done for nova/ipa integration:
* is specific to ipa - it uses ipa specific apis, files, commands, etc.
* does a lot more than just DNS registration - it configures the system 
to allow ssh into the system, to allow kerberos auth, HBAC including 
based on hostgroup, etc. - this is the demo I did for OpenStack Tokyo: 
http://richmegginson.livejournal.com/27573.html

Rob Crittenden, Juan Osorio Robles, and Adam Young have helped with this 
effort and have extended it since then.

It unfortunately relies on unsupported internal nova apis (hooks), and 
there will be a discussion in Austin about how to do this going forward.

>
>>>
>>>>>> 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
>>
>
> __________________________________________________________________________
> 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