Open Stack

On Tue, Apr 5, 2016 at 2:45 PM, Fox, Kevin M <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> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosorior at gmail.com
>
>
> __________________________________________________________________________
> 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/4ecb9b3e/attachment.html>