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