On Wed, Apr 6, 2016 at 5:04 PM, Adam Young <[email protected]> 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: [email protected]?subject:un >>>>> subs >>>>> cribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> ___________________________________________________________________ >>>> _______ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: [email protected]?subject:unsu >>>> bscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> _____________________________________________________________________ >>> _____ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?subject:unsubs >>> cribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
