[Openstack-operators] OpenStack services and ca certificate config entries

Jesse Keating jlk at bluebox.net
Wed Mar 25 18:13:38 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150325/e027d440/attachment.html>


More information about the OpenStack-operators mailing list