Open Stack

From: "duncan.thomas at gmail.com<mailto:duncan.thomas at gmail.com>" <duncan.thomas at gmail.com<mailto:duncan.thomas at gmail.com>>
Reply-To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, November 30, 2015 at 9:13 AM
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 30 November 2015 at 16:04, Coffman, Joel M. <Joel.Coffman at jhuapl.edu<mailto:Joel.Coffman at jhuapl.edu>> wrote:
On 11/25/15, 11:33 AM, "Ben Swartzlander" <ben at swartzlander.org<mailto:ben at swartzlander.org>> wrote:

On 11/24/2015 03:27 PM, Nathan Reller wrote:
Trying to design a system where we expect nova to do data encryption but
not cinder will not work in the long run. The eventual result will be
that nova will have to take on most of the functionality of cinder and
we'll be back to the nova-volume days.
Could you explain further what you mean by "nova will have to take on most of the functionality of cinder"? In the current design, Nova is still passing data blocks to Cinder for storage – they're just encrypted instead of plaintext. That doesn't seem to subvert the functionality of Cinder or reimplement it.

The functionality of cinder is more than blindly storing blocks - in particular it has create-from/upload-to image, backup, and retype, all of which do some degree of manipulation of the data and/or volume encryption metadata.
From a security perspective, it is advantageous for users to be able to upload an encrypted image, copy that image to a volume, and boot from that volume without decrypting the image until it is booted.

We are suffering from somewhat incompatible requirements with encryption between those who want fully functional cinder and encryption on disk (the common case I think), and those who have enhanced security requirements.
The original design supports this distinction: there is a "control-location" parameter that indicates where encryption is to be performed (see http://docs.openstack.org/user-guide-admin/dashboard_manage_volumes.html).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151202/a337d397/attachment.html>