> 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.
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. 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]). [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] 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
