Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:un
> > > subs
> > > 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:unsu
> > bscribe
> > 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev