On 12/2/15, 4:01 PM, "Ben Swartzlander" <b...@swartzlander.org> wrote:
>On 11/30/2015 09:04 AM, Coffman, Joel M. wrote: >> >> >> On 11/25/15, 11:33 AM, "Ben Swartzlander" <b...@swartzlander.org >> <mailto:b...@swartzlander.org>> 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). So perhaps it would be fair to describe the existing encryption support as comparable to the proposal to use LUKS inside the guest VM? >> 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 > >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. The operations listed seem to have the same issues with encryption inside a VM and the existing implementation. 1) Create volume from Glance image: Since Glance doesn't support encryption (yet), this volume would be unencrypted and any discussion about encryption is a moot point. 2) Create Glance image from volume: If the volume is encrypted (using encryption inside the VM or the current implementation), then eventually trying to use this image to boot a VM will fail *unless* there is a way to provide the key when the image is spawned. If Glance eventually supports the same encryption metadata as Cinder, then the current implementation should "just work." 3) Backup / restore volume: Encryption inside the VM has the same issues as the current implementation. Of course, both techniques (encryption inside a VM and the current implementation) have significant implications regarding compression, de-duplication, etc. That was the original rationale for including the 'control-location' parameter: it explicitly admits multiple ways of handling the encryption and would allow users to determine if the additional storage cost is worth it. >> 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. Thanks for this clarification! __________________________________________________________________________ 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
