Open Stack

On 15 January 2016 at 14:18, Major Hayden <major at mhtx.net> wrote:
>
>
> 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.
>
> 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.
>
> 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.
>
> Thanks!
>
> [1] https://wiki.openstack.org/wiki/Security/Projects/Anchor
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077877.html
> [3] https://review.openstack.org/#/c/243332/
> [4] https://etherpad.openstack.org/p/openstack-ansible-tls-improvement


Major - fantastic initiative.

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.

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:

1 - consistency in the deployment of certificates and configuration of
services (consistency improves ease of use)
2 - simplicity of deployment - for example making it easy to apply one set
of certs across the board
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
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.

Thanks to both yourself and Jean-Philippe for taking this on!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160208/279c9e9a/attachment.html>