[openstack-dev] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?

Clark, Robert Graham robert.clark at hpe.com
Mon Nov 9 15:46:12 UTC 2015


> -----Original Message-----
> From: Adam Young [mailto:ayoung at redhat.com]
> Sent: 02 November 2015 20:54
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?
> 
> On 10/26/2015 02:38 PM, Major Hayden wrote:
> > Hello there,
> >
> > I've been researching some additional ways to secure openstack-ansible deployments and I backed myself into a corner with secure log
> transport.  The rsyslog client requires a trusted CA certificate to be able to send encrypted logs to rsyslog servers.  That's not a problem if
> users bring their own certificates, but it does become a problem if we use the self-signed certificates that we're creating within the various
> roles.
> >
> > I'm wondering if we could create a role that creates a CA on the deployment host and then uses that CA to issue certificates for various
> services *if* a user doesn't specify that they want to bring their own certificates.  We could build the CA very early in the installation
> process and then use it to sign certificates for each individual service.  That would allow to have some additional trust in environments
> where deployers don't choose to bring their own certificates.
> >
> > Does this approach make sense?
> >
> > --
> > Major Hayden
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> FreeIPA has a Dogtag server that can be your full CA.  I would recommend
> not rolling our own.
> 
> We have a playbook that does this here:
> https://github.com/admiyo/rippowam  specifically in the
> https://github.com/admiyo/rippowam/tree/master/roles/ipaserver  role
> 

Fundamentally everything is self-signed at its root. Who your systems trust depends on which certificates are installed in your system CA bundles,  which can be something Ansible takes care of or some other magic - you can distribute corporate CA certs or even specificly created local CA certs depending on your requirements.

A note on ephemeral certs - (Anchor or otherwise) the point here is that revocation works pretty poorly in Linux and especially poorly with the crypto libraries available to python today (CRL distribution is pretty non-deterministic at scale and OCSP just isn't supported) so in reality, your best mechanism could be to issue only short term certificates and replace them often, if you need to revoke a certificate you don't replace it. This technique is actually pretty CA agnostic, I imagine you could easily configure Dogtag, FreeIPA, EJBCA, ADCS etc to issue short life certificates.

The sticking point with short-life certificates is that the lifecycle is so short that when working at any sort of scale automated certificate signing is required, so robust policy management is required, automating a large part of what a traditional Registration Authority (RA) would do - which is a problem we've tried to solve with Anchor.

So I guess for any project you need to consider how/if revocation will work, in truth most of the time it doesn't, we pretend it does and carry on worrying about making sure we use publicly signed certificates.

I agree that running a local letsencrypt has a lot of promise here, it again looks at replacing a traditional RA with various proofs of possession or control (like control of specific DNS records etc).

There are ways to make most services play nice with ephemeral certificates - generally it involves front ending the service with a TLS terminator or LB - we've found through testing that they're generally pretty good at having certificates (and keys) swapped out from under them.





More information about the OpenStack-dev mailing list