[openstack-dev] [tripleo] Encrypted swift volumes by default in the undercloud

[Juan Antonio Osorio]

Hello!

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?

[1] https://review.openstack.org/#/c/567200/

BR

[Dmitry Tantsur]

Hi,

Post by Juan Antonio Osorio
Hello!
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?

Post by Juan Antonio Osorio
[1] https://review.openstack.org/#/c/567200/
BR
--
Juan Antonio Osorio R.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Doug Hellmann]

Post by Dmitry Tantsur

Post by Juan Antonio Osorio
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
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?

It seems like we should add "some form of key manager" to the base
service lists, shouldn't we? And then we would encourage projects to use
castellan to talk to it. Unless we want to try to pick a single key
manager, which feels like a much longer sort of conversation.

Doug