Open Stack

On Wed, Apr 6, 2016 at 4:06 AM, Dan Prince <dprince at redhat.com> 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.
>

Actually, even if we start using Barbican, which wouldn't also be a bad
idea. It still needs a backend. The default settings for Barbican are not
suitable for usage in production. One of the supported backends is DogTag
(which is deployed with FreeIPA). But ellaborating on this, using only
Barbican (with Dogtag as a backend) doesn't really address the issue, but
merely puts a REST interface on top of the problem. We would then need to
come up with a solution that we can propose to nova and further propose a
blueprint. Which is similar to what Kevin Fox once tried to do.

>
> 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.
>
> >
> > 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-request at lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160406/9152cf23/attachment.html>