[openstack-dev] [TripleO] FreeIPA integration
rmeggins at redhat.com
Wed Apr 6 01:19:22 UTC 2016
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
>> 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
>> 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
>> a development or testbed setup. But we need to make it possible to
>> secure an end deployment, and FreeIPA was designed explicitly for
>> kinds of distributed applications. Here is what I would like to
>> Assuming that the Undercloud is installed on a physical machine, we
>> to treat the FreeIPA server as a managed service of the undercloud
>> 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
>> the FreeIPA server on the undercloud. So, while I would like to see
>> 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
>> I was also able to run FreeIPA in a container on the undercloud
>> but this is, I think, not how we want to migrate to a container
>> 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
>> between with-FreeIPA and without-FreeIPA. Thus, I suspect the right
>> approach is to run the overcloud deploy, then "harden" the
>> 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?
>> So, big question: is Heat->ansible (instead of Puppet) for an
>> deployment an acceptable path? We are talking Ansible 1.0
>> which should be relatively straightforward ports to 2.0 when the time
>> 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
>> 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
>> for securing the message broker. Since Rabbit seems to be the tool
>> choice, we would use X509 authentication and TLS for
>> encryption. ACLs,
>> for now, would stay in the flat file format. In the future, we
>> 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
>> 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
>> original implementation.
>> 2. Juan Antonio Osorio has been working on TLS everywhere. The
>> thus far has been Certificate management. This provides a Dogtag
>> for Certs.
>> 3. Rob Crittenden has been working on auto-registration of virtual
>> machines with an Identity Provider upon launch. This gives that
>> an IdM to use.
>> 4. Keystone can make use of the Identity store for administrative
>> in their own domain.
>> 5. Many of the compliance audits have complained about cleartext
>> passwords in config files. This removes most of them. MySQL
>> X509 based authentication today, and there is Kerberos support in
>> works, which should remove the last remaining cleartext Passwords.
>> I mentioned Centralized SUDO and HBAC. These are both tools that may
>> used by administrators if so desired on the install. I would
>> 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev