Open Stack

Having an extra node for FreeIPA spawn up by heat works for me. And it's
not a hard-requirement that we have to wire this into the TripleO CI. But
the most sustainable approach to having TLS everywhere (at least for the
admin and internal endpoints of Openstack, the message broker server nodes
and the database) is using FreeIPA as a CA. So if we advertise (at some
point) that TripleO will support such a feature, then it's probably a good
idea to have it in the official CI.

BR

On Tue, Apr 5, 2016 at 4:01 PM, Steven Hardy <shardy at redhat.com> wrote:

> On Tue, Apr 05, 2016 at 02:07:06PM +0300, Juan Antonio Osorio wrote:
> >    On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy <shardy at redhat.com>
> wrote:
> >
> >      On Sat, Apr 02, 2016 at 05:28:57PM -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.
> >      >
> >      > 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.
> >
> >      IMO these services shouldn't be deployed on the undercloud - we only
> >      support a single node undercloud, and atm it's completely possible
> to
> >      take
> >      the undercloud down without any impact to your deployed cloud (other
> >      than
> >      losing the ability to manage it temporarily).
> >
> >    This is fair enough, however, for CI purposes, would it be acceptable
> to
> >    deploy it there? Or where do you recommend we have it?
>
> We're already well beyond capacity in CI, so to me this seems like
> something that's probably appropriate for a third-party CI job?
>
> To me it just doesn't make sense to integrate these pieces on the
> undercloud, and integrating it there just because we need it available for
> CI purposes seems like a poor argument, because we're not testing a
> representative/realistic environment.
>
> If we have to wire this in to TripleO CI I'd favor spinning up an extra
> node with the FreeIPA pieces in, e.g a separate Heat stack (so, e.g the
> nonha job takes 3 nodes, a "freeipa" stack of 1 and an overcloud of 2).
>
> Steve
>
> __________________________________________________________________________
> 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/20160405/aca221bd/attachment.html>