[openstack-dev] [Tripleo] X509 Management

Juan Antonio Osorio jaosorior at gmail.com
Tue Jun 21 20:17:31 UTC 2016


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

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

 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?

>
> 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
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> 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/b1ccb360/attachment.html>


More information about the OpenStack-dev mailing list