On the certificate management side I had presented this blueprint* https://review.openstack.org/#/c/282307/ <https://review.openstack.org/#/c/282307/> *which proposes FreeIPA as the reference solution. There the steps are described however, I did leave away where the FreeIPA instance will be installed, and that was on purpose. Because first I want to figure out proper integration (since now the nova-hooks are not an option and we will need another mechanism) and on the other hand, I wanted to figure out where to put it.
Now, for CI, I have the same view as Adam; It would be very beneficial to have that in the same node as the undercloud. But if that's not possible, I would like to discuss different alternatives. On Sun, Apr 3, 2016 at 12:28 AM, Adam Young <ayo...@redhat.com> 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. > > 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. > Why not? I think this is quite a reasonable thing to do for testing purposes. CI, for example. > > > 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. > > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Juan Antonio Osorio R. e-mail: jaosor...@gmail.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev