Open Stack

Adam, this is pretty much the proposal for TLS for the internal services
(which you were added already as a reviewer for the spec)
https://review.openstack.org/#/c/282307/
The services in the overcloud fetching their certificates via certmonger is
actually work in progress, which you could review here:
https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
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).
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.

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

On Tue, Jun 21, 2016 at 5:39 PM, Adam Young <ayoung at redhat.com> wrote:

> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
>
> 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.
>
> __________________________________________________________________________
> 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
>



-- 
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160621/60ec0efb/attachment.html>