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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
