Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)
On 2018-05-16 17:42:09 + (+), Jeremy Stanley wrote: [...] > 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 [...] As Jim Rollenhagen pointed out in #openstack-tc, I was probably thinking of the earlier Pike PTG session the Architecture WG held, summarized at: http://lists.openstack.org/pipermail/openstack-dev/2017-February/113016.html Ensuing discussion yielded that there was no good reason to rename a library even if the Oslo team was going to officially adopt it (which for castellan they subsequently did in March 2017). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)
Excerpts from Jeremy Stanley's message of 2018-05-16 17:42:09 +: > 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? 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
