Open Stack

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" <ben at swartzlander.org
>> <mailto:ben at 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).
> 
>>     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:
>> 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



Best wishes
Lisa