The issue here is the key manager, barbican, under development is in incubation. Folks can download and use barbican. The barbican team has worked deligently to produce the system. In fact, folks can download and use and vote for Joel's patch to be merged. And do give us feedback on barbican.
The chicken-egg problem .. and the desire to keep the key manager as a separate service entails the incubation requirement. Regards Malini ________________________________________ From: Joe Gordon [joe.gord...@gmail.com] Sent: Tuesday, September 03, 2013 6:06 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [nova] key management and Cinder volume encryption On Tue, Sep 3, 2013 at 5:41 PM, Coffman, Joel M. <joel.coff...@jhuapl.edu<mailto:joel.coff...@jhuapl.edu>> wrote: > How can someone use your code without a key manager? Some key management mechanism is required although it could be simplistic. For example, we’ve tested our code internally with an implementation of the key manager interface that returns a single, constant key. That works for testing but doesn't address: "the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment" I think the underlying issue is how to handle interrelated features – if Nova doesn’t want to accept the volume encryption feature without a full-fledged key manager, then why accept a key manager (or its interface stubs) unless it already has a feature that requires it (e.g., volume encryption)? And round-and-round it goes. You can propose both patches at the same time one being dependent on the other, so we can merge both at the same time I’d also like to point out that the volume encryption feature is “complete” and won’t require changes when a full-fledged key manager becomes available. All that’s needed is to specify the key manager via a configuration option. So this request is definitely *not* a case of trying to land a feature that isn’t finished and is disabled by default (see [1], [2], and [3]). Is a feature complete if no one can use it? I am happy with a less then secure but fully functional key manager. But with no key manager that can be used in a real deployment, what is the value of including this code? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008244.html [2] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008315.html [3] http://lists.openstack.org/pipermail/openstack-dev/2013-April/008268.html From: Joe Gordon [mailto:joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>] Sent: Tuesday, September 03, 2013 4:48 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [nova] key management and Cinder volume encryption On Tue, Sep 3, 2013 at 4:38 PM, Coffman, Joel M. <joel.coff...@jhuapl.edu<mailto:joel.coff...@jhuapl.edu>> wrote: We have fully implemented support for transparently encrypting Cinder volumes<https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes> from within Nova (see https://review.openstack.org/#/c/30976/), but the lack of a secure key manager within OpenStack currently precludes us from integrating our work with that piece of the overall architecture. Instead, a key manager interface (see https://review.openstack.org/#/c/30973/) abstracts this interaction. We would appreciate the consideration of the Nova core team regarding merging our existing work because 1) there is nothing immediately available with which to integrate; 2) services such as Barbican<https://launchpad.net/cloudkeep/+announcements> are on the path to incubation and alternative key management schemes (e.g., KMIP Client for volume encryption key management<https://blueprints.launchpad.net/nova/+spec/kmip-client-for-volume-encryption>) have also been proposed; 3) we avoid the hassle of rebasing until the aforementioned services become available; and 4) our code does not directly depend upon a particular key manager but upon the aforementioned interface, which should be simple for key managers to implement. Furthermore, the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment; although the security is diminished, our implementation provides protection against certain attacks like intercepting the iSCSI communication between the compute and storage host. How can someone use your code without a key manager? Feedback regarding the possibility of merging our work would be appreciated. Joel _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
