> -----Original Message----- > From: Ben Swartzlander [mailto:b...@swartzlander.org] > Sent: Friday, December 4, 2015 2:45 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick > > On 12/03/2015 07:40 AM, Duncan Thomas wrote: > > On 3 December 2015 at 11:14, Li, Xiaoyan <xiaoyan...@intel.com > > <mailto:xiaoyan...@intel.com>> wrote: > > > > Just to clear the data operations cinder needs to touch plaintext > > data are: > > 1) Create volume from glance image > > 2) Create glance image from volume > > 3) Retype encrypted volumes. That is to change a volume from > > unencrypted to encrypted, or vice visa. > > > > Backup/Restore doesn't need to decrypt data. > > > > > > Backup / restore doesn't currently decrypt the data. There are some > > people commenting that it is not useful for DR work to have a backup > > that requires keys from a key service that is itself not backed up, so > > there may be some proposal incoming about not encrypting backups, or > > else giving them their own key rather than require access to the > > original volume key during restore - needing that access also makes > > things like re-keying the original volume difficult/impossible. > > > > Again, we have multiple use-cases for encryption, and they are not all > > going to be solved by solved by draconian dictates that there shall > > only be one way of doing things. > > There are other very good reasons for multiple encryption keys for > different purposes. Client side data encryption is known to prevent server- > side compression and deduplication technologies from working at all, and > it makes backups wildly less efficient. The upshot is that if choose to do > implement security by encryption everything in the guest or hypervisor > rather than in the storage controller, you're going to spend a ton more on > disks. > > Assuming your threat model involves evil people sniffing network wires, > and pulling disks from machines in the datacenter, rather than assuming to > storage admin himself is evil, you can devise schemes that involve separate > encryption for in-flight data and at-rest data which allow the storage > controller to do compression and deduplication and store your data in both > a secure AND EFFICIENT manner. > > The above isn't a future fantasy -- there are storage controllers that do this > TODAY with unmodified cinder and nova. You just need a storage > controller that features full-disk-encryption and also transport level > security (such as blocks over Kerberized NFS) as well as the compression > and deduplication technologies which are quickly becoming standardized.
Yeah, another point I can think is that when backup restores, it can use different encryptions, like key, key_size, and algorithm. > > -Ben > > > > > _____________________________________________________________ > _________ > > ____ 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 > > > > > _____________________________________________________________ > _____________ > 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 __________________________________________________________________________ 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
