Thank you, Ben. I agree with you, and just to clear the cinder operations which needs to decrypt volumes in following.
On Dec 3, 2015 05:01, Ben Swartzlander wrote: > On 11/30/2015 09:04 AM, Coffman, Joel M. wrote: >> >> >> On 11/25/15, 11:33 AM, "Ben Swartzlander" <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 11/24/2015 03:27 PM, Nathan Reller wrote: >> the cinder admin and the nova admin are ALWAYS the same >> people >> >> >> There is interest in hybrid clouds where the Nova and Cinder >> services are managed by different providers. The customer would >> place higher trust in Nova because you must trust the compute >> service, and the customer would place less trust in Cinder. One >> way to achieve this would be to have all encryption done by >> Nova. Cinder would simply see encrypted data and provide a good >> cheap storage solution for data. >> >> Consider a company with sensitive data. They can run the >> compute nodes themselves and offload Cinder service to some >> third-party service. This way they are the only ones who can >> manage the machines that see the plaintext. >> >> If you have that level of paranoia, I suggest running LUKS inside >> the guest VM and not relying on OpenStack to handle your >> encryption. Then you don't have to worry about whether nova is >> sharing your keys with cinder because even nova won't have them. >> That approach isn't actually more secure - anyone with root access to >> the compute host can dump the VM's memory to extract the encryption > keys. > > I agree, however in the above case there was implied trust in the compute > infrastructure -- at least more so than in the storage infrastructure. If you > don't trust your hypervisor admin to not read your VM memory and steal > encryption keys, then relying on your hypervisor admin (or nova) to > perform the encryption is kind of silly. > In every case, the hypervisor admin can see the plaintext and the keys. > > The suggestion was a way to achieve the goal of doing encryption > WITHOUT trusting the storage admin and WITHOUT CHANGING ANY CODE. > I assert that any attempt to implement encryption at the nova level and not > sharing keys with cinder will break the existing model. There are 2 > solutions I can see: > 1) don't break it (see above) > 2) you break it, you fix it (nova takes over responsibility for all the > operations cinder currently performs that involve plaintext). > >> 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. > > I think Duncan covered it, but the data operations cinder currently > performs, which require Cinder to touch plaintext data are: > 1) Create volume from glance image > 2) Create glance image from volume > 3) Backup volume > 4) Restore volume 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. > > I'm not claiming that we can't redefine or alter the above operations to > deal with encryption, but someone needs to propose how they should work > differently or work at all when the volume isn't storing plaintext data. > >> Also in case it's not obvious, if you use different providers for >> compute and storage, your performance is going to be absolutely >> terrible. >> The general idea is probably separation of duties, which contradicts >> the original statement that "the cinder admin and the nova admin are >> ALWAYS the same people." Is there an operational reason that these >> admins must be the same person, or is that just typical? > > My assertion was to try to combat confusion about the roles of the "storage > admin". Many people who don't deal with storage all the time tend to > forgot that cinder is a management tool that's separate from actual > hardware which stores bits. It's common to have a "storage admin" > who is responsible for configuration and management of storage hardware > and software but to have Cinder run by an "openstack admin" who is a > customer/client of the storage admin. > > My belief is that it's FAR more common for cinder to be installed and run > by the same guy (or group) who installs/runs nova, than for the the > 2 services to be run by 2 entirely different groups, whereas it _is_ fairly > common to have different groups dedicated to managing physical servers > vs physical storage controllers. > >> Joel >> >> >> >> > _____________________________________________________________ > _________ >> ____ OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _____________________________________________________________ _____________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev- [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Best wishes Lisa __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
