<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 10:51 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span>
<div>On 06/21/2016 02:42 PM, Juan Antonio
Osorio wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Adam, this is pretty much the proposal for TLS for the
internal services (which you were added already as a
reviewer for the spec) <a href="https://review.openstack.org/#/c/282307/" target="_blank">https://review.openstack.org/#/c/282307/</a>
<br>
</div>
The services in the overcloud fetching their certificates via
certmonger is actually work in progress, which you could
review here: <a href="https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger" target="_blank">https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger</a><br>
</div>
<div>Only thing is that currently this approach assumes FreeIPA,
so the nodes need to be registered beforehand (and then
trigger self-enrollment via some hooks).<br>
</div>
<div>Also, the spec that I'm pointing to doesn't require the CA
to be the in undercloud and it could be another node. But hey,
if we could deploy Anchor on the Undercloud, then that could
be used, so we wouldn't need another node for this means.<br>
</div>
</div>
</blockquote>
<br>
<br></span>
Yes, I was basing my proposal her around your work. I want there to
be something guaranteed for Certmonger to talk to, and I realize
that Heat can probably play that role.<br>
<br>
Anchor might also be viable here, I just don't want to force it as a
dependency. We are talking the selfsigned use case here, so it
should be minimal overhead.<span><br></span></div></blockquote><div> </div><div> I think it's a better idea to have Anchor as a dependency than try to brew CA functionality into Heat via os-*-config. Maybe a Heat person can answer this? Then for more complex use-cases we can use FreeIPA. Do we have Anchor packetized in RDO?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Anyway, in each of the service's profiles (the puppet
manifests) I'm setting up the tracking of the certificates
with the certmonger's puppet manifest.<br>
</div>
<div><br>
</div>
<div>BR<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jun 21, 2016 at 5:39 PM, Adam
Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When
deploying the overcloud with TLS, the current "no additional
technology" approach is to use opensssl and self signed.
While this works for a Proof of concept, it does not make
sense if the users need to access the resources from remote
systems.<br>
<br>
It seems to me that the undercloud, as the system of record
for deploying the overcloud, should be responsible for
centralizing the signing of certificates.<br>
<br>
When deploying a service, the puppet module sure trigger a
getcert call, which registers the cert with Certmonger.
Certmonger is responsible for making sure the CSR gets to
the signing authority, and fetching the cert.<br>
<br>
Certmonger works via helper apps. While there is currently
a "self signed" helper, this does not do much if two or more
systems need to have the same CA sign their certs.<br>
<br>
It would be fairly simple to write a certmonger helper
program that sends a CSR from a controller or compute node
to the undercloud, has the Heat instance on the undercloud
validate the request, and then pass it on to the signing
application.<br>
<br>
I'm not really too clear on how callbacks are done from the
os-collect-config processes to Heat, but I am guessing it is
some form of Rest API that could be reused for this work
flow?<br>
<br>
<br>
I would see this as the lowest level of deployment. We can
make use of Anchor or Dogtag helper apps already. This
might also prove a decent middleground for people that need
an automated approach to tie in with a third party CA, where
they need some confirmation from the deployment process that
the data in the CSR is valid and should be signed.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<div><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2">Juan
Antonio Osorio R.<br>
e-mail: <a href="mailto:jaosorior@gmail.com" target="_blank">jaosorior@gmail.com</a><br>
</font><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2"><br>
</font></div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2">Juan Antonio Osorio R.<br>e-mail: <a href="mailto:jaosorior@gmail.com" target="_blank">jaosorior@gmail.com</a><br></font><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2"><br></font></div></div></div>
</div></div>