On Nov 23, 2015 22:34, Daniel P. Berrange wrote: > On Mon, Nov 23, 2015 at 07:05:05AM +0100, Philipp Marek wrote: >>> About uploading encrypted volumes to image, there are three options: >>> 1. Glance only keeps non-encrypted images. So when uploading > encrypted >>> volumes to image, cinder de-crypts the data and upload. 2. Glance >>> maintain encrypted images. Cinder just upload the encrypted data to >>> image. >>> 3. Just prevent the function to upload encrypted volumes to images. >>> >>> Option 1 No changes needed in Glance. But it may be not safe. As we >>> decrypt the data, and upload it to images. Option 2 This imports >>> encryption to Glance which needs to manage the encryption metadata. >>> >>> Please add more if you have other suggestions. How do you think which > one is preferred. >> Well, IMO only option 1 is useful. >> >> Option 2 means that the original volume, the image, and all derived >> volumes will share the same key, right? > > That depends on how you implement it really. If you directly upload the > encrypted volume as-is, and then directly boot later VMs of the same > image, as-is they'll obviously share the same key. It is possible though for > cinder to re-encrypt the volume with a different key before uploading it, or > more likely for Nova to re-encrypt the image with a different key after > downloading it to boot an instance.
Could any people from Glance say anything? As I heard that there were problems When nova boots from an encrypted image if Glance keeps encrypted images. > >> That's not good. (Originally: "unacceptable") > > If the images and all volumes are all owned by a single tenant user it is not > a big deal if they have the same key. Depending on what threats you are > protecting against, it may be more desirable than having the data stored > unencrypted in glance. > > Regards, > Daniel Best wishes Lisa __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
