[openstack-dev] [nova] Which SSL ca_file does a person use, really?

Jim Rollenhagen jim at jimrollenhagen.com
Fri Apr 1 17:56:53 UTC 2016


On Fri, Apr 01, 2016 at 11:07:40AM -0500, Matt Riedemann wrote:
> We have a lot of CA file options in nova:
> 
> 1. DEFAULT.ca_file - this is used in nova.crypto
> 2. ssl.ca_file - this is used when constructing glanceclient
> 3. DEFAULT.ssl_ca_file - this is used in nova.wsgi
> 4. vmware.ca_file - for connecting to vcenter
> 5. neutron.cafile - for constructing neutronclient
> 6. cinder.cafile - for constructing cinderclient
> 7. keystone_authtoken.cafile - for constructing keystoneauth
> 8. barbican.cafile - for constructing barbicanclient

+ ironic.cafile - for constructing ironicclient.
https://github.com/openstack/nova/commit/0230edd708eb961ad6f9afb88a778fe03320bf3e

> 
> As far as I can see none of these are deprecated. The keystone_auth one is
> probably coming from one of the keystone library options, so we can't do
> much about that.
> 
> But it seems like the first three, and then the other ones for connecting to
> neutron/cinder/barbican clients could all be collapsed, or is that not the
> intent?

I think in most cases they could, and I don't think anybody is going to
say it shouldn't be in this email.

However, I'd be willing to bet there's some cloud out there where at
least one of these services is owned by a separate team than Nova, who
uses a different CA than the rest of things.

// jim

> 
> I remember Matthew Gilliard working on something related to this at one
> point where we were going to use a DictOpt where the default value comes
> from ssl.ca_file (which is defined in oslo.service) but you could override
> that for specific functions, like if you want different files for connecting
> to the different clients.
> 
> Is anyone else working on something like this because it's super confusing
> for deployers.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list