Open Stack

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

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
>