On 06/21/2016 02:42 PM, Juan Antonio Osorio wrote:
Adam, this is pretty much the proposal for TLS for the internal
services (which you were added already as a reviewer for the spec)
https://review.openstack.org/#/c/282307/
The services in the overcloud fetching their certificates via
certmonger is actually work in progress, which you could review here:
https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
Only thing is that currently this approach assumes FreeIPA, so the
nodes need to be registered beforehand (and then trigger
self-enrollment via some hooks).
Also, the spec that I'm pointing to doesn't require the CA to be the
in undercloud and it could be another node. But hey, if we could
deploy Anchor on the Undercloud, then that could be used, so we
wouldn't need another node for this means.
Yes, I was basing my proposal her around your work. I want there to be
something guaranteed for Certmonger to talk to, and I realize that Heat
can probably play that role.
Anchor might also be viable here, I just don't want to force it as a
dependency. We are talking the selfsigned use case here, so it should
be minimal overhead.
Anyway, in each of the service's profiles (the puppet manifests) I'm
setting up the tracking of the certificates with the certmonger's
puppet manifest.
BR
On Tue, Jun 21, 2016 at 5:39 PM, Adam Young <ayo...@redhat.com
<mailto:ayo...@redhat.com>> wrote:
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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com <mailto:jaosor...@gmail.com>
__________________________________________________________________________
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
__________________________________________________________________________
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
