Open Stack

On 06/21/2016 02:42 PM, Juan Antonio Osorio wrote:
> 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.


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.

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.
>
> 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 
> <mailto: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://OpenStack-dev-request@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 <mailto:jaosorior at gmail.com>
>
>
>
> __________________________________________________________________________
> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160621/0ec5c128/attachment.html>