<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>But definitely +1 on consistent config option naming, at a minimum.</div>
<div><br>
</div>
<div>Mike</div>
<div><br>
</div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Erik McCormick<br>
<span style="font-weight:bold">Date: </span>Wednesday, March 25, 2015 at 9:36 PM<br>
<span style="font-weight:bold">To: </span>Michael Still<br>
<span style="font-weight:bold">Cc: </span>Jesse Keating, OpenStack Operators<br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack-operators] OpenStack services and ca certificate config entries<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">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.<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 25, 2015 at 6:33 PM, Michael Still <span dir="ltr">
<<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks for starting this thread Jesse. I agree that heat looks like a<br>
good model for other projects to model themselves on here.<br>
<br>
Can anyone think of a use case for having a per client / driver CA<br>
file? I can't, but perhaps I'm missing something.<br>
<br>
</blockquote>
<div>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.</div>
<div><br>
</div>
<div style="font-size:12.8000001907349px">[clients]</div>
<div><span style="font-size:12.8000001907349px">ca_file = <path></span></div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Michael<br>
<div class="">
<div class="h5"><br>
On Thu, Mar 26, 2015 at 5:13 AM, Jesse Keating <<a href="mailto:jlk@bluebox.net">jlk@bluebox.net</a>> wrote:<br>
> We're facing a bit of a frustration. In some of our environments, we're<br>
> using a self-signed certificate for our ssl termination (haproxy). We have<br>
> our various services pointing at the haproxy for service cross-talk, such as<br>
> nova to neutron or nova to glance or nova to cinder or neutron to nova or<br>
> cinder to glance or all the things to keystone. When using a self-signed<br>
> certificate, these services have trouble validating the cert when they<br>
> attempt to talk to each other. This problem can be solved in a few ways,<br>
> such as adding the CA to the system bundle (of your platform has such a<br>
> thing), adding the CA to the bundle python requests uses (because<br>
> hilariously it doesn't always use the system bundle), or the more direct way<br>
> of telling nova, neutron, et al the direct path to the CA file.<br>
><br>
> This last choice is the way we went forward, more explicit, and didn't<br>
> depend on knowledge if python-requests was using its own bundle or the<br>
> operating system's bundle. To configure this there are a few places that<br>
> need to be touched.<br>
><br>
> nova.conf:<br>
> [keystone_authtoken]<br>
> cafile = <path><br>
><br>
> [neutron]<br>
> ca_certificates_file = <path><br>
><br>
> [cinder]<br>
> ca_certificates_file = <path><br>
><br>
> (nothing for glance hilariously)<br>
><br>
><br>
> neutron.conf<br>
> [DEFAULT]<br>
> nova_ca_certificates_file = <path><br>
><br>
> [keystone_authtoken]<br>
> cafile = <path><br>
><br>
> glance-api.conf and glance-registry.conf<br>
> [keystone_authtoken]<br>
> cafile = <path><br>
><br>
> cinder.conf<br>
> [DEFAULT]<br>
> glance_ca_certificates_file = <path><br>
><br>
> [keystone_authtoken]<br>
> cafile = <path><br>
><br>
> heat.conf<br>
> [clients]<br>
> ca_file = <path><br>
><br>
> [clients_<whatever>]<br>
> ca_file = <path><br>
><br>
><br>
> As you can see, there are a lot of places where one would have to define the<br>
> path, and the frustrating part is that the config name and section varies<br>
> across the services. Does anybody think this is a good thing? Can anybody<br>
> think of a good way forward to come to some sort of agreement on config<br>
> names? It does seem like heat is a winner here, it has a default that can be<br>
> defined for all clients, and then each client could potentially point to a<br>
> different path, but every config entry is named the same. Can we do that<br>
> across all the other services?<br>
><br>
> I chatted a bit on twitter last night with some nova folks, they suggested<br>
> starting a thread here on ops list and potentially turning it into a hallway<br>
> session or real session at the Vancouver design summit (which operators are<br>
> officially part of).<br>
><br>
> - jlk<br>
><br>
</div>
</div>
<span class="im">> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
><br>
<br>
<br>
<br>
</span><span class=""><font color="#888888">--<br>
Rackspace Australia<br>
</font></span>
<div class="">
<div class="h5"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">-Erik</div>
</div>
</div>
</div>
</span>
</body>
</html>