Open Stack

> 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.gordon0 at 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.Coffman at jhuapl.edu<mailto:Joel.Coffman at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130903/2be1c9ea/attachment.html>