Open Stack

Yeah, and they just deprecated vendor data plugins too, which eliminates my other workaround. :/

We need to really discuss this problem at the summit and get a viable path forward. Its just getting worse. :/

Thanks,
Kevin
________________________________
From: Juan Antonio Osorio [jaosorior at gmail.com]
Sent: Tuesday, April 05, 2016 5:16 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration



On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>> wrote:
This sounds suspiciously like, "how do you get a secret to the instance to get a secret from the secret store" issue.... :)
Yeah, sounds pretty familiar. We were using the nova hooks mechanism for this means, but it was deprecated recently. So bummer :/

Nova instance user spec again?

Thanks,
Kevin

________________________________
From: Juan Antonio Osorio
Sent: Tuesday, April 05, 2016 4:07:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] FreeIPA integration



On Tue, Apr 5, 2016 at 11:36 AM, Steven Hardy <shardy at redhat.com<mailto: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?

These auth pieces all appear critical to the operation of the deployed
cloud, thus I'd assume you really want them independently managed (probably
in an HA configuration on multiple nodes)?

So, I'd say we support one of:

1. Document that FreeIPA must exist, installed by existing non-TripleO
tooling

2. Support a heat template (in addition to overcloud.yaml) that can deploy
FreeIPA.

I feel like we should do (1), as it fits better with the TripleO vision
(which is to deploy OpenStack), and it removes the need for us to maintain
a bunch of non-openstack stuff.

The path I'm imagining is we have a documented integration with FreeIPA,
and perhaps some third-party CI, but we don't support deploying these
pieces directly via TripleO.

> 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.

I think we should require the IPA layer to be installed first - I mean
isn't it likely in many (most?) production environments that these services
already exist?

This simplifies things, because then you just pass inputs from the existing
proven IPA environment in as a tripleo/heat environment file - same model
we already support for all kinds of vendor integration, SSL etc etc.

> 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.

In short, no.  I don't see how you can do the hardening with ansible,
unless you're proposing to reimplement the entire overcloud deployment in
the same tool.

The data required to configure the OpenStack services should be passed in
via an environment file, e.g

openstack overcloud deploy --templates -e ipa-params.yaml

Then all the data from ipa-params.yaml should be mapped into hieradata
which puppet then uses to configure the OpenStack services appropriately -
this is the same model we support for integration with  everything atm.

While it's technically possible to configure an overcloud, then reconfigure
it with some other tool (or even manually), you get the worst of all worlds
doing this - you modify things out-of-band (from a TripleO perspective) so
that all your changed get destroyed every overcloud update, and you run the
risk of "config management split brain" where e.g puppet configures a
service disabled, then ansible starts it or whatever.

> 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.

This should be:

1. Install and validate IPA server $somewhere
2. Generate environment file with parameters (this could be automated)
3. Install overcloud passing in environment file with IPA $stuff
4. Done
This is an acceptable solution IMO and was according to what I was thinking. It will also be easier to setup the overcloud with FreeIPA specific configurations once we have the composable services work done.

To me, the biggest interrogation is what the value of that $somewhere is. To me, for testing purposes it seemed acceptable to have FreeIPA running in the same node as the undercloud. And in production it would be a separate node (or set of nodes).

Basically *anything* touching the overcloud configuration should happen via
puppet in our current architecture, which I think means (4) and (5).

I'm less clear about (3) - this sounds like an IPA admin action, can it be
done before deploying the overcloud, or do we need each node to register
itself?
The nodes need to get the IPA client installation which pretty much involves enrollment. For this, they need to have some type of credentials. So this is the main thing Rob is working towards. To have a safe method to pass credentials to the nodes, and have them autoregister to FreeIPA.

Similarly not sure about (6), probably need more info about what that
entails.

> 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.

Aha, this may be the answer to (3) above?  E.g the discussion around nova
hooks?

> 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.

Overall this sounds like a bunch of functionality we want, but I think the
integration requires more discussion (possibly at summit?) - my main
concern is that we integrate in a manner appropriate to our existing
implementation, and that we don't inadvertently make the undercloud a
mission-critical component, when it current is not.

Thanks,

Steve

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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<mailto:jaosorior at gmail.com>


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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<mailto:jaosorior at gmail.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160405/ba803616/attachment-0001.html>