[openstack-dev] [cinder][nova]Move encryptors to os-brick

Li, Xiaoyan xiaoyan.li at intel.com
Mon Dec 7 08:56:29 UTC 2015


> -----Original Message-----
> From: Ben Swartzlander [mailto:ben at 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.li at intel.com
> > <mailto:xiaoyan.li at 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-request at 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list