Open Stack

Hi,

Except creating encrypted volume from images, uploading encrypted volumes to image, as Duncan said there is desire to migrate volumes between encrypted and unencrypted type.
https://review.openstack.org/#/c/248593/

And key magagment codes are duplicated in Cinder and Nova:
https://github.com/openstack/cinder/tree/master/cinder/keymgr
https://github.com/openstack/nova/tree/master/nova/keymgr


Best wishes
Lisa

From: Duncan Thomas [mailto:duncan.thomas at gmail.com]
Sent: Monday, November 23, 2015 8:29 PM
To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

Hi Daniel
Much of this got discussed before.

Encrypted images uploaded to glance aren't shareable, and there is definitely a desire by many users to keep the usual glance functionality while having encryption at rest in cinder for e.g. regulatory purposes.
There is also some desire to be able to migrate unencrypted volume types to encrypted types inside cinder, which would require cinder to be able to create an encrypted volume in a similar way to creating from an image.

Managing access to the key data is, as far as I'm aware, the job of e.g. barbican/castellan, not nova per se. There are several usecases for encryption, and several of the less paranoid make good sense without requiring nova to be the only thing with access to the key material.


On 23 November 2015 at 13:21, Daniel P. Berrange <berrange at redhat.com<mailto:berrange at redhat.com>> wrote:
On Fri, Nov 20, 2015 at 11:34:29AM -0800, Walter A. Boring IV wrote:
> On 11/20/2015 10:19 AM, Daniel P. Berrange wrote:
> >On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote:
> >>Brick does not have to take over the decisions in order to be a useful
> >>repository for the code. The motivation for this work is to avoid having
> >>the dm setup code copied wholesale into cinder, where it becomes difficult
> >>to keep in sync with the code in nova.
> >>
> >>Cinder needs a copy of this code since it is on the data path for certain
> >>operations (create from image, copy to image, backup/restore, migrate).
> >A core goal of using volume encryption in Nova to provide protection for
> >tenant data, from a malicious storage service. ie if the decryption key
> >is only ever used by Nova on the compute node, then cinder only ever sees
> >ciphertext, never plaintext.  Thus if cinder is compromised, then it can
> >not compromise any data stored in any encrypted volumes.
> >
> >If cinder is looking to get access to the dm-seutp code, this seems to
> >imply that cinder will be getting access to the plaintext data, which
> >feels to me like it de-values the volume encryption feature somewhat.
> >
> >I'm fuzzy on the details of just what code paths cinder needs to be
> >able to convert from plaintext to ciphertext or vica-verca, but in
> >general I think it is desirable if we can avoid any such operation
> >in cinder, and keep it so that only Nova compute nodes ever see the
> >decrypted data.
> Being able to limit the number of points where an encrypted volume can be
> used unencrypted
> is obviously a good goal.
> Unfortunately, it's entirely unrealistic to expect Cinder to never be able
> to have access that access.
>
> Cinder currently needs access to write data to volumes that are encrypted
> for several operations.
>
> 1) copy volume to image
If a volume is encrypted and it is being copied to an image, IMHO we
should not aim to decrypt it. We should copy the data as is and mark
the image as encrypted in glance, and then use it as is next time the
image is needed.

FYI, Nova is already aiming to consider both the glance data storage
and the glance service as a whole, as untrustworthy. The first step
in this is using cryptographic signatures to detect unauthorized
image data modification by a compromised glance. Encryption will be
a later step in the process.

> 2) copy image to volume

This is semi-plausible as a place where Cinder needs to go from
unencrypted image data to encrypted volume data, when a user is
creating a volume from an image ahead of time, distinct from any
VM boot attempt. In such a case it is desirable that Cinder not
be able to request any existing volume keys from the key server,
merely have the ability to upload new keys and throw away its
local copy thereafter.

> 3) backup

Cinder should really not try to decrypt volumes when backing them
up. If it conversely wants to encrypt volumes during backup, it
can do so with separate backup keys, distinct from those used for
primary volume encryption for use at runtime.


Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
--
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/3d01d694/attachment.html>