<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 October 2015 at 12:43, Major Hayden <span dir="ltr"><<a href="mailto:major@mhtx.net" target="_blank">major@mhtx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 10/29/2015 04:33 AM, McPeak, Travis wrote:<br>
> The only potential security drawback is that we are introducing a new<br>
> asset to protect.  If we create the tools that enable a deployer to<br>
> easily create and administer a lightweight CA, that should add<br>
> significant value to OpenStack, especially for smaller organizations<br>
> that don't have experience running a CA.<br>
<br>
</span>This is certainly true.  However, I'd like to solve for the use of self-signed SSL certificates in openstack-ansible first.<br>
<br>
At the moment, each self-signed certificate for various services is generated within each role.  The goal would be to make a CA at the beginning and then allow roles to utilize another role/task to issue certificates from that CA.  The CA would most likely be located on the deployment host.<br>
<br>
Deployers who are very security conscious can provide keys, certificates, and CA certificates in the deployment configuration and those will be used instead of generating self-signed certificates.<br>
<div class=""><div class="h5"></div></div></blockquote></div><br>
</div><div class="gmail_extra">I would argue that self-signed certificates only provide an illusion of security and the tasks we have to generate and distribute them should be removed entirely. My thinking is that if a deployer wants to use self-signed certs, then the deployer can create them and provide their details as user-provided certs. That way we can do without a whole block of code and the dependency on memcache for distribution. This makes the decision to use the self-signed certs a more deliberate one and also takes care of the complexity of certificate distribution.</div><div class="gmail_extra"><br></div><div class="gmail_extra">That said, I applaud the idea of using a CA role. There are a few in Ansible Galaxy, but I've found their implementations to be rather complex whereas I think they can be pretty simple. I have actually done a fair amount of work on the CA setup part of things in my not-yet-complete ansible-openvas role [1]. You are welcome to use this work as a starting base and develop a role which sets up a CA. The trouble I found when looking into how to do this properly was that there should be several CA's (one offline primary and more than one secondary which actually does the signing). This will mean that the role will require quite a bit of guidance for using it correctly and setting up a single CA or multi-CA environment.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Whether you develop a new role for the OpenStack-Ansible toolbox, or develop documentation for consuming an existing role in Ansible Galaxy, the concept is certainly welcome and would go a long way to simplifying a secure-by-default implementation of OpenStack.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="https://github.com/odyssey4me/ansible-openvas/blob/master/tasks/install_openssl_ca.yml">https://github.com/odyssey4me/ansible-openvas/blob/master/tasks/install_openssl_ca.yml</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">---</div><div class="gmail_extra">Jesse</div><div class="gmail_extra">IRC: odyssey4me</div></div>