<div dir="ltr"><div>On the certificate management side I had presented this blueprint<i> <a href="https://review.openstack.org/#/c/282307/">https://review.openstack.org/#/c/282307/</a> </i>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.<br><br></div>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.<br><div><i></i><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 3, 2016 at 12:28 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
<br>
FreeIPA is an identity management solution that can provide support for:<br>
<br>
1. TLS on all network communications:<br>
A. HTTPS for web services<br>
B. TLS for the message bus<br>
C. TLS for communication with the Database.<br>
2. Identity for all Actors in the system:<br>
A. API services<br>
B. Message producers and consumers<br>
C. Database consumers<br>
D. Keystone service users<br>
3. Secure DNS DNSSEC<br>
4. Federation Support<br>
5. SSH Access control to Hosts for both undercloud and overcloud<br>
6. SUDO management<br>
7. Single Sign On for Applications running in the overcloud.<br>
<br>
<br>
The main pieces of FreeIPA are<br>
1. LDAP (the 389 Directory Server)<br>
2. Kerberos<br>
3. DNS (BIND)<br>
4. Certificate Authority (CA) server (Dogtag)<br>
5. WebUI/Web Service Management Interface (HTTPD)<br>
<br>
Of these, the CA is the most critical. Without a centralized CA, we have no reasonable way to do certificate management.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div>Why not? I think this is quite a reasonable thing to do for testing purposes. CI, for example. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
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.<br>
<br>
<br>
The IdM team did just this last summer in preparing for the Tokyo summit, using Ansible and Packstack. The Rippowam project <a href="https://github.com/admiyo/rippowam" rel="noreferrer" target="_blank">https://github.com/admiyo/rippowam</a> 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.<br>
<br>
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.<br>
<br>
Thus, the sequence would be:<br>
<br>
1. Run existing overcloud deploy steps.<br>
2. Install IPA server on the allocated VM<br>
3. Register the compute nodes and the controller as IPA clients<br>
4. Convert service users over to LDAP backed services, complete with necessary kerberos steps to do password-less authentication.<br>
5. Register all web services with IPA and allocate X509 certificates for HTTPS.<br>
6. Set up Host based access control (HBAC) rules for SSH access to overcloud machines.<br>
<br>
<br>
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.<br>
<br>
<br>
There are a couple ongoing efforts that will tie in with this:<br>
<br>
1. Designate should be able to use the DNS from FreeIPA. That was the original implementation.<br>
<br>
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.<br>
<br>
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.<br>
<br>
4. Keystone can make use of the Identity store for administrative users in their own domain.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2">Juan Antonio Osorio R.<br>e-mail: <a href="mailto:jaosorior@gmail.com" target="_blank">jaosorior@gmail.com</a><br></font><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2"><br></font></div></div></div>
</div></div></div></div>