<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 January 2016 at 14:18, Major Hayden <span dir="ltr"><<a href="mailto:major@mhtx.net" target="_blank">major@mhtx.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I've attended some of the OpenStack Security Mid-Cycle meeting this week and Robert Clark was kind enough to give me a deep dive on the Anchor project[1].  We had a good discussion around my original email thread[2] on improving SSL/TLS certificates within OpenStack-Ansible (OSA) and we went over my proposed spec[3] on the topic.<br>
<br>
Jean-Philippe Evrard helped me assemble an etherpad[4] this morning where we brainstormed some problem statements, user stories, and potential solutions for improving the certificate experience in OSA.  It seems like an ephemeral PKI solution, like Anchor, might provide a better certificate experience for users while also making the revocation and issuance process easier.<br>
<br>
I'd really like to get some feedback from the OpenStack community on our current brainstorming efforts.  We've enumerated a few use cases and user stories already, but we've probably missed some other important ones.  Feel free to stop by #openstack-ansible or join us in the etherpad.<br>
<br>
Thanks!<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Security/Projects/Anchor" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Security/Projects/Anchor</a><br>
[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-October/077877.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-October/077877.html</a><br>
[3] <a href="https://review.openstack.org/#/c/243332/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/243332/</a><br>
[4] <a href="https://etherpad.openstack.org/p/openstack-ansible-tls-improvement" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/openstack-ansible-tls-improvement</a></blockquote><div><br></div><div>Major - fantastic initiative.</div><div><br></div><div>One thing I'd like to say is to remind you that OSA is a toolbox of roles and plays that a deployer can mix and match to suit the needs of the specific environment.</div><div><br></div><div>This effectively means that we could easily curate or consume Ansible roles which do any of the options outlined as possible solutions. What we care about mostly is:</div><div><br></div><div>1 - consistency in the deployment of certificates and configuration of services (consistency improves ease of use)</div><div>2 - simplicity of deployment - for example making it easy to apply one set of certs across the board</div><div>3 - modularity - retain the ability to apply a different cert to any one service, and the ability to have TLS/SSL on for some and not for others</div><div>4 - testing - we need to be able to gate test services individually, and in end-to-end scenario's. Each possible scenario costs time, effort and gate resources - so ideally we want to reduce our first class tested scenario's but implement everything in such a way that we have a high level of confidence that replacing one certificate generation method with another will not change the result.</div><div><br></div><div>Thanks to both yourself and Jean-Philippe for taking this on!</div></div>
</div></div>