[openstack-dev] [TripleO] FreeIPA integration
Emilien Macchi
emilien at redhat.com
Thu Apr 7 12:04:55 UTC 2016
On Wed, Apr 6, 2016 at 5:04 PM, Adam Young <ayoung at redhat.com> wrote:
> On 04/06/2016 10:44 AM, Dan Prince wrote:
>>
>> On Tue, 2016-04-05 at 19:19 -0600, Rich Megginson wrote:
>>>
>>> On 04/05/2016 07:06 PM, Dan Prince wrote:
>>>>
>>>> On Sat, 2016-04-02 at 17:28 -0400, 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)
>>>>>
>>>>> Of these, the CA is the most critical. Without a centralized CA,
>>>>> we
>>>>> have no reasonable way to do certificate management.
>>>>
>>>> Would using Barbican to provide an API to manage the certificates
>>>> make
>>>> more sense for our deployment tooling? This could be useful for
>>>> both
>>>> undercloud and overcloud cases.
>>>>
>>>> As for the rest of this, how invasive is the implementation of
>>>> FreeIPA.? Is this something that we can layer on top of an existing
>>>> deployment such that users wishing to use FreeIPA can opt-in.
>>>>
>>>>> Now, I know a lot of people have an allergic reaction to some,
>>>>> maybe
>>>>> all, of these technologies. They should not be required to be
>>>>> running
>>>>> in
>>>>> a development or testbed setup. But we need to make it possible
>>>>> to
>>>>> secure an end deployment, and FreeIPA was designed explicitly for
>>>>> these
>>>>> kinds of distributed applications. Here is what I would like to
>>>>> implement.
>>>>>
>>>>> Assuming that the Undercloud is installed on a physical machine,
>>>>> we
>>>>> want
>>>>> to treat the FreeIPA server as a managed service of the
>>>>> undercloud
>>>>> that
>>>>> is then consumed by the rest of the overcloud. Right now, there
>>>>> are
>>>>> conflicts for some ports (8080 used by both swift and Dogtag)
>>>>> that
>>>>> prevent a drop-in run of the server on the undercloud
>>>>> controller. Even
>>>>> if we could deconflict, there is a possible battle between
>>>>> Keystone
>>>>> and
>>>>> the FreeIPA server on the undercloud. So, while I would like to
>>>>> see
>>>>> the
>>>>> ability to run the FreeIPA server on the Undercloud machine
>>>>> eventuall, I
>>>>> think a more realistic deployment is to build a separate virtual
>>>>> machine, parallel to the overcloud controller, and install
>>>>> FreeIPA
>>>>> there. I've been able to modify Tripleo Quickstart to provision
>>>>> this
>>>>> VM.
>>>>>
>>>>> I was also able to run FreeIPA in a container on the undercloud
>>>>> machine,
>>>>> but this is, I think, not how we want to migrate to a container
>>>>> based
>>>>> strategy. It should be more deliberate.
>>>>>
>>>>>
>>>>> While the ideal setup would be to install the IPA layer first,
>>>>> and
>>>>> create service users in there, this produces a different install
>>>>> path
>>>>> between with-FreeIPA and without-FreeIPA. Thus, I suspect the
>>>>> right
>>>>> approach is to run the overcloud deploy, then "harden" the
>>>>> deployment
>>>>> with the FreeIPA steps.
>>>>>
>>>>>
>>>>> The IdM team did just this last summer in preparing for the Tokyo
>>>>> summit, using Ansible and Packstack. The Rippowam project
>>>>> https://github.com/admiyo/rippowam was able to fully lock down a
>>>>> Packstack based install. I'd like to reuse as much of Rippowam
>>>>> as
>>>>> possible, but called from Heat Templates as part of an overcloud
>>>>> deploy. I do not really want to re implement Rippowam in Puppet.
>>>>
>>>> As we are using Puppet for our configuration I think this is
>>>> currently
>>>> a requirement. There are many good puppet examples out there of
>>>> various
>>>> servers and a quick google search showed some IPA modules are
>>>> available
>>>> as well.
>>>>
>>>> I think most TripleO users are quite happy in using puppet modules
>>>> for
>>>> configuration in that the puppet openstack modules are quite mature
>>>> and
>>>> well tested. Making a one-off exception for FreeIPA at this point
>>>> doesn't make sense to me.
>>>
>>> What about calling an ansible playbook from a puppet module?
>>
>> Given our current toolset in TripleO having the ability to manage all
>> service configurations with a common language overrides any short cuts
>> that calling Ansible from Puppet would give you I think.
>>
>> The best plan I think for IPA integration into the Over and underclouds
>> would be a puppet-freeipa module.
>
> Puppet is fine. I have some feedback from the IPA side that the
> https://github.com/purpleidea/puppet-ipa/ works ok. Work on it seems to
> have tapered off last June, but we could revive.
If we go Puppet, I would like to investigate which module we can use.
Here's a list of modules able to deploy IPA:
https://forge.puppet.com/tags/freeipa
We might want to take one with the less dependencies as possible,
tests, frequent releases and good quality of code.
>
>>
>>>>> So, big question: is Heat->ansible (instead of Puppet) for an
>>>>> overcloud
>>>>> deployment an acceptable path? We are talking Ansible 1.0
>>>>> Playbooks,
>>>>> which should be relatively straightforward ports to 2.0 when the
>>>>> time
>>>>> comes.
>>>>>
>>>>> Thus, the sequence would be:
>>>>>
>>>>> 1. Run existing overcloud deploy steps.
>>>>> 2. Install IPA server on the allocated VM
>>>>> 3. Register the compute nodes and the controller as IPA clients
>>>>> 4. Convert service users over to LDAP backed services, complete
>>>>> with
>>>>> necessary kerberos steps to do password-less authentication.
>>>>> 5. Register all web services with IPA and allocate X509
>>>>> certificates
>>>>> for
>>>>> HTTPS.
>>>>> 6. Set up Host based access control (HBAC) rules for SSH access
>>>>> to
>>>>> overcloud machines.
>>>>>
>>>>>
>>>>> When we did the Rippowam demo, we used the Proton driver and
>>>>> Kerberos
>>>>> for securing the message broker. Since Rabbit seems to be the
>>>>> tool
>>>>> of
>>>>> choice, we would use X509 authentication and TLS for
>>>>> encryption. ACLs,
>>>>> for now, would stay in the flat file format. In the future, we
>>>>> might
>>>>> chose to use the LDAP backed ACLs for Rabbit, as they seem far
>>>>> more
>>>>> flexible. Rabbit does not currently support Kerberos for either
>>>>> authentication or encryption, but we can engage the upstream team
>>>>> to
>>>>> implement it if desired in the future, or we can shift to a
>>>>> Proton
>>>>> based
>>>>> deployment if Kerberos is essential for a deployment.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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:un
>>>>> subs
>>>>> cribe
>>>>> 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:unsu
>>>> bscribe
>>>> 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:unsubs
>>> cribe
>>> 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
--
Emilien Macchi
More information about the OpenStack-dev
mailing list