On Tue, Jun 21, 2016 at 10:51 PM, Adam Young <ayo...@redhat.com> wrote:
> 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. > I think it's a better idea to have Anchor as a dependency than try to brew CA functionality into Heat via os-*-config. Maybe a Heat person can answer this? Then for more complex use-cases we can use FreeIPA. Do we have Anchor packetized in RDO? > > 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> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Juan Antonio Osorio R. > e-mail: jaosor...@gmail.com > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 > > -- Juan Antonio Osorio R. e-mail: 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
