Open Stack

On 04/05/2016 09: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.
Barbican is not a CA.  However, it can use the KRA deployed with Dogtag 
to store its secrets, so this actually supports Barbican nicely.

>
> 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.
Yep.  The big thing it gives you is the Cert management, and I don't 
want to rewrite that, but the rest can stay out of the way.

I do suspect that, once it is there, we will want to use more of IPA, 
but that is not the goal.



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

Yeah, and I think I am fine with that.  It just means I have to rewrite 
some stuff, and that makes sense in keeping thing consistent.  Just 
figured I'd ask first before I had to star getting deep into Puppet.

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