-----Original Message----- From: John Dennis <[email protected]> Reply: OpenStack Development Mailing List (not for usage questions) <[email protected]> Date: June 21, 2016 at 10:28:22 To: OpenStack Development Mailing List (not for usage questions) <[email protected]>, Adam Young <[email protected]> Subject: Re: [openstack-dev] [Tripleo] X509 Management
> On 06/21/2016 10:55 AM, Ian Cordasco wrote: > > -----Original Message----- > > From: Adam Young > > Reply: OpenStack Development Mailing List (not for usage questions) > > > > Date: June 21, 2016 at 09:40:39 > > To: OpenStack Development Mailing List > > 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 I didn't get that. *Starts thinking of suggesting OSA adopting certmonger* -- Ian Cordasco __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
