[openstack-dev] [Tripleo] X509 Management
Ian Cordasco
sigmavirus24 at gmail.com
Tue Jun 21 14:55:17 UTC 2016
-----Original Message-----
From: Adam Young <ayoung at redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Tripleo] X509 Management
> 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.
I'm not familiar with TripleO or it's use of puppet, but I would
strongly advocate for Anchor (or DogTag) to be the recommended
solution. OpenStack Ansible has found it a little bit of an annoyance
to generate and distribute self-signed certificates.
--
Ian Cordasco
More information about the OpenStack-dev
mailing list