[openstack-dev] [TripleO] FreeIPA integration
Juan Antonio Osorio
jaosorior at gmail.com
Tue Apr 5 11:00:41 UTC 2016
On the certificate management side I had presented this blueprint*
<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 <ayoung at 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
> 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
> 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-request at lists.openstack.org?subject:unsubscribe
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev