Open Stack

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.

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