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
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
