I was planning to bring it up informally for TripleO. But it would be cool to have a slot to talk about this.
BR On 5 Apr 2016 18:51, "Fox, Kevin M" <kevin....@pnnl.gov> wrote: > 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 [jaosor...@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....@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 <sha...@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-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Juan Antonio Osorio R. >> e-mail: jaosor...@gmail.com >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Juan Antonio Osorio R. > e-mail: jaosor...@gmail.com > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev