On 2018-05-16 13:16:09 +0200 (+0200), Dmitry Tantsur wrote: > On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote: > > As part of the work from the Security Squad, we added the > > ability for the containerized undercloud to encrypt the > > overcloud plans. This is done by enabling Swift's encrypted > > volumes, which require barbican. Right now it's turned off, but > > I would like to enable it by default [1]. What do you folks > > think? > > I like the idea, but I'm a bit skeptical about adding a new > service to already quite bloated undercloud. Why is barbican a > hard requirement here? [...]
This exchange has given me pause to reflect on discussions we were having one year ago (leading up to and at the Forum in Boston). https://www.openstack.org/summit/boston-2017/summit-schedule/events/18736/key-management-developeroperatorcommunity-coordination https://etherpad.openstack.org/p/BOS-forum-key-management As a community, we're likely to continue to make imbalanced trade-offs against relevant security features if we don't move forward and declare that some sort of standardized key storage solution is a fundamental component on which OpenStack services can rely. Being able to just assume that you can encrypt volumes in Swift, even as a means to further secure a TripleO undercloud, would be a step in the right direction for security-minded deployments. Unfortunately, I'm unable to find any follow-up summary on the mailing list from the aforementioned session, but recollection from those who were present (I had a schedule conflict at that time) was that a Castellan-compatible key store would at least be a candidate for inclusion in our base services list: https://governance.openstack.org/tc/reference/base-services.html So a year has passed... where are we with this? Is it still something we want to do (I think so, do others)? What are the next steps so this doesn't come up again and again? -- Jeremy Stanley
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
