Open Stack

On 06/21/2016 11:26 AM, John Dennis wrote:
> 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

Exactly.  This allows the interface from Tripleo to be the same 
regardless of the CA.


I am looking for guidance from the Tripleo/Heat team on how to structure 
the certmonger helper app.