Open Stack

-----Original Message-----
From: John Dennis <jdennis at redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: June 21, 2016 at 10:28:22
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>, Adam Young <ayoung at redhat.com>
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