Open Stack

On 11/20/2015 10:19 AM, Daniel P. Berrange wrote:
> On Fri, Nov 20, 2015 at 02:45:15PM +0200, Duncan Thomas wrote:
>> Brick does not have to take over the decisions in order to be a useful
>> repository for the code. The motivation for this work is to avoid having
>> the dm setup code copied wholesale into cinder, where it becomes difficult
>> to keep in sync with the code in nova.
>>
>> Cinder needs a copy of this code since it is on the data path for certain
>> operations (create from image, copy to image, backup/restore, migrate).
> A core goal of using volume encryption in Nova to provide protection for
> tenant data, from a malicious storage service. ie if the decryption key
> is only ever used by Nova on the compute node, then cinder only ever sees
> ciphertext, never plaintext.  Thus if cinder is compromised, then it can
> not compromise any data stored in any encrypted volumes.
>
> If cinder is looking to get access to the dm-seutp code, this seems to
> imply that cinder will be getting access to the plaintext data, which
> feels to me like it de-values the volume encryption feature somewhat.
>
> I'm fuzzy on the details of just what code paths cinder needs to be
> able to convert from plaintext to ciphertext or vica-verca, but in
> general I think it is desirable if we can avoid any such operation
> in cinder, and keep it so that only Nova compute nodes ever see the
> decrypted data.
Being able to limit the number of points where an encrypted volume can 
be used unencrypted
is obviously a good goal.
Unfortunately, it's entirely unrealistic to expect Cinder to never be 
able to have access that access.
Cinder currently needs access to write data to volumes that are 
encrypted for several operations.

1) copy volume to image
2) copy image to volume
3) backup

Cinder already has the ability to do this for encrypted volumes. What 
Lisa Li's patch is trying to provide
is a single point of shared code for doing encryptors.  os-brick seems 
like a reasonable place to put this
as it could be shared with other services that need to do the same 
thing, including Nova, if desired.

There is also ongoing work to support attaching Cinder volumes to bare 
metal nodes.  The client that does the
attaching to a bare metal node, will be using os-brick connectors to do 
the volume attach/detach.  So, it makes
sense from this perspective as well that the encryptor code lives in 
os-brick.

I'm ok with the idea of moving common code into os-brick.  This was the 
main reason os-brick was created
to begin with.
Walt