<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 3, 2013 at 5:41 PM, Coffman, Joel M. <span dir="ltr"><<a href="mailto:Joel.Coffman@jhuapl.edu" target="_blank">Joel.Coffman@jhuapl.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div class="im">
<p class="">> How can someone use your code without a key manager?<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p></div><p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.</span></p>
</div></div></blockquote><div>That works for testing but doesn't address: "<span style="font-size:13px;font-family:arial,sans-serif">the current dearth of key management within OpenStack does not preclude the use of our existing work within a production environment" </span></div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div><p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.</span></p>
</div></div></blockquote><div><br></div><div>You can propose both patches at the same time one being dependent on the other, so we can merge both at the same time</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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 *<b>not</b>* a case of trying to land a feature that isn’t finished and is disabled by default (see [1], [2], and [3]).</span></p>
</div></div></blockquote><div>Is a feature complete if no one can use it? </div><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div>
<p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/008244.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-April/008244.html</a><u></u><u></u></span></p>
<p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/008315.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-April/008315.html</a><u></u><u></u></span></p>
<p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">[3] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/008268.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-April/008268.html</a><u></u><u></u></span></p>
<p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class=""><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class=""><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Joe Gordon [mailto:<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>] <br>
<b>Sent:</b> Tuesday, September 03, 2013 4:48 PM<br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] [nova] key management and Cinder volume encryption<u></u><u></u></span></p><div><div class="h5">
<p class=""><u></u> <u></u></p><div><p class=""><u></u> <u></u></p><div><p class="" style="margin-bottom:12pt"><u></u> <u></u></p><div><p class="">On Tue, Sep 3, 2013 at 4:38 PM, Coffman, Joel M. <<a href="mailto:Joel.Coffman@jhuapl.edu" target="_blank">Joel.Coffman@jhuapl.edu</a>> wrote:<u></u><u></u></p>
<div><div><p class="">We have fully implemented support for <a href="https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes" target="_blank">transparently encrypting Cinder volumes</a> from within Nova (see <a href="https://review.openstack.org/#/c/30976/" target="_blank">https://review.openstack.org/#/c/30976/</a>), 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 <a href="https://review.openstack.org/#/c/30973/" target="_blank">https://review.openstack.org/#/c/30973/</a>) 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 <a href="https://launchpad.net/cloudkeep/+announcements" target="_blank">Barbican</a> are on the path to incubation and alternative key management schemes (e.g., <a href="https://blueprints.launchpad.net/nova/+spec/kmip-client-for-volume-encryption" target="_blank">KMIP Client for volume encryption key management</a>) 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.<u></u><u></u></p>
<p class=""> <u></u><u></u></p></div></div><div><p class=""><u></u> <u></u></p></div><div><p class="">How can someone use your code without a key manager?<u></u><u></u></p></div><div><p class=""> <u></u><u></u></p></div>
<div>
<p class=""><u></u> <u></u></p></div><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="">
Feedback regarding the possibility of merging our work would be appreciated.<u></u><u></u></p><p class=""><span style="color:rgb(136,136,136)"> <u></u><u></u></span></p><p class=""><span style="color:rgb(136,136,136)">Joel<u></u><u></u></span></p>
</div></div><p class="" style="margin-bottom:12pt"><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p></blockquote></div><p class=""><u></u> <u></u></p>
</div></div></div></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>