Open Stack

On 06/21/2016 10:55 AM, Ian Cordasco wrote:
> -----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.

Ah, but the idea is that certmonger is a front to whatever CA you chose 
to use, it provides a consistent interface to a range of CA's as well as 
providing functionality not present in most CA's, for instance the 
ability detect when certs need renewal etc. So the idea would be 
certmonger+Dogtag or certmongner+Anchor, or certmonger+XXX
-- 
John