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 <[email protected]>
Reply: OpenStack Development Mailing List (not for usage questions)
<[email protected]>
Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List
<[email protected]>
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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
