FYI - http://lists.openstack.org/pipermail/openstack-dev/2014-June/037238.html happened over the summer, which at least normalizes the names. I felt like bits of this conversation were familiar. That's all in projects in Kilo.
I do agree that single CA seems like a more sensible default than currently needing multiple sections in the nova.conf (as an example). That's basically a raw export of the complexity of the underlying code and should be addressed. On 03/26/2015 12:52 AM, Mike Dorman wrote: > I have struggled with this stuff in the past, too. And have had > situations where certs come from different CAs, so I can see some value > in an ability to override the global defaults for specific services. > > However, for the small fraction of use cases that would cover, I think > the cert concatenation solution/work-around is sufficient. I can’t > really think of why one couldn’t/wouldn’t do that. > > But definitely +1 on consistent config option naming, at a minimum. > > Mike > > > From: Erik McCormick > Date: Wednesday, March 25, 2015 at 9:36 PM > To: Michael Still > Cc: Jesse Keating, OpenStack Operators > Subject: Re: [Openstack-operators] OpenStack services and ca certificate > config entries > > I'll start by saying I went the system bundle route also and have thus > far had no issues with it. I'll also say that I'm using RDO packages > still and not doing anything with venvs or pip installed stuff. > > On Wed, Mar 25, 2015 at 6:33 PM, Michael Still <mi...@stillhq.com > <mailto:mi...@stillhq.com>> wrote: > > Thanks for starting this thread Jesse. I agree that heat looks like a > good model for other projects to model themselves on here. > > Can anyone think of a use case for having a per client / driver CA > file? I can't, but perhaps I'm missing something. > > There could potentially be instances where one service would be running > certificates issued off of one internal CA and others on another, but > really I don't see the point of splitting them out when you can > concatenate the CA certificates together and feed it in as a bundle that > covers everything. This one section from Heat would cover everything I > would think. > > [clients] > ca_file = <path> > > > Michael > > On Thu, Mar 26, 2015 at 5:13 AM, Jesse Keating <j...@bluebox.net > <mailto:j...@bluebox.net>> wrote: > > We're facing a bit of a frustration. In some of our environments, we're > > using a self-signed certificate for our ssl termination (haproxy). We > have > > our various services pointing at the haproxy for service cross-talk, > such as > > nova to neutron or nova to glance or nova to cinder or neutron to nova > or > > cinder to glance or all the things to keystone. When using a self-signed > > certificate, these services have trouble validating the cert when they > > attempt to talk to each other. This problem can be solved in a few ways, > > such as adding the CA to the system bundle (of your platform has such a > > thing), adding the CA to the bundle python requests uses (because > > hilariously it doesn't always use the system bundle), or the more > direct way > > of telling nova, neutron, et al the direct path to the CA file. > > > > This last choice is the way we went forward, more explicit, and didn't > > depend on knowledge if python-requests was using its own bundle or the > > operating system's bundle. To configure this there are a few places that > > need to be touched. > > > > nova.conf: > > [keystone_authtoken] > > cafile = <path> > > > > [neutron] > > ca_certificates_file = <path> > > > > [cinder] > > ca_certificates_file = <path> > > > > (nothing for glance hilariously) > > > > > > neutron.conf > > [DEFAULT] > > nova_ca_certificates_file = <path> > > > > [keystone_authtoken] > > cafile = <path> > > > > glance-api.conf and glance-registry.conf > > [keystone_authtoken] > > cafile = <path> > > > > cinder.conf > > [DEFAULT] > > glance_ca_certificates_file = <path> > > > > [keystone_authtoken] > > cafile = <path> > > > > heat.conf > > [clients] > > ca_file = <path> > > > > [clients_<whatever>] > > ca_file = <path> > > > > > > As you can see, there are a lot of places where one would have to > define the > > path, and the frustrating part is that the config name and section > varies > > across the services. Does anybody think this is a good thing? Can > anybody > > think of a good way forward to come to some sort of agreement on config > > names? It does seem like heat is a winner here, it has a default that > can be > > defined for all clients, and then each client could potentially point > to a > > different path, but every config entry is named the same. Can we do that > > across all the other services? > > > > I chatted a bit on twitter last night with some nova folks, they > suggested > > starting a thread here on ops list and potentially turning it into a > hallway > > session or real session at the Vancouver design summit (which operators > are > > officially part of). > > > > - jlk > > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org > <mailto:OpenStack-operators@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > > -- > Rackspace Australia > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > <mailto:OpenStack-operators@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > -Erik > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
