Open Stack

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.

Michael

On Thu, Mar 26, 2015 at 5:13 AM, Jesse Keating <jlk at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Rackspace Australia