On Tue, Sep 3, 2013 at 5:41 PM, Coffman, Joel M. <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] > *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> > 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 > 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev