yahoo-eng-team team mailing list archive

[Daniel Berrange <1639293@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

When making an API call to Cinder to get the volume encryption metadata:

2016-10-25 05:30:47.048 6699 DEBUG cinderclient.v2.client [req-7fe1959f-
36f6-4dd6-bf47-f5e550d59530 3fdb4fc839fc44a9a99006d3fb75ac4d
c6b14fd5fffa48aa8eb869f30c80e409 - - -] REQ: curl -g -i -X GET
http://192.168.1.13:8776/v2/c6b14fd5fffa48aa8eb869f30c80e409/volumes/9439e922-1051-4d83-87c7-172689ac29da/encryption
-H "User-Agent: python-cinderclient" -H "Accept: application/json" -H "X
-Auth-Token: {SHA1}4ff393589c57548e39cca7b5ed99d8a42d1ac7fa"
_http_log_request /usr/lib/python2.7/site-
packages/keystoneauth1/session.py:337

The reply from cinder includes a fully qualified name of a nova private
class:

2016-10-25 05:30:47.100 6699 DEBUG cinderclient.v2.client [req-7fe1959f-36f6-4dd6-bf47-f5e550d59530 3fdb4fc839fc44a9a99006d3fb75ac4d c6b14fd5fffa48aa8eb869f30c80e409 - - -] RESP: [200] X-Compute-Request-Id: req-4e32d4e4-3c02-4fdf-8179-7c9825f446e3 Content-Type: application/json Content-Length: 209 X-Openstack-Request-Id: req-4e32d4e4-3c02-4fdf-8179-7c9825f446e3 Date: Tue, 25 Oct 2016 09:30:47 GMT Connection: keep-alive 
RESP BODY: {"cipher": "aes-xts-plain64", "encryption_key_id": "00000000-0000-0000-0000-000000000000", "provider": "nova.volume.encryptors.cryptsetup.CryptsetupEncryptor", "key_size": 256, "control_location": "front-end"}
 _http_log_response /usr/lib/python2.7/site-packages/keystoneauth1/session.py:366


THis is very bad for a number of reasons

 - If nova renames its classes, existing encryption breaks because the classs names no longer match what cinder is sending
 - It allows out of tree extensions to nova for different encryption impls, which consume Nova private data structures in method calls. THis is against Nova policy - all such other extension points have been deprected, then removed.
 - If nova wants to implement encryption in a different way (eg by delegating to QEMU), then the concept of an encryptor class does not even apply.


This is actually even worse than Cinder merely passing class names across. Cinder in fact exposes this in its public REST API to tenant users, letting tenants specify arbitrary encryptor classname for nova to use:

http://docs.openstack.org/mitaka/config-reference/block-storage/volume-
encryption.html

$ cinder encryption-type-create --cipher aes-xts-plain64 --key_size 512 \
  --control_location front-end LUKS nova.volume.encryptors.luks.LuksEncryptor


The idea of having the tenant user specify arbitrary nova private class names needs to be removed entirely. Instead we should have an enum of encryption *formats*. Any given format may be implemented by Nova in a variety of ways. Nova will look at the format and decide which encryptor class to use (if any), or decide how to configure QEMU natively to use that format.

For back compat we can't drop use of class names immediately, so we'll
need a deprecation period.

In Ocata:

 - Cinder and Nova should allow an encryption format enum to be used in
the 'provider' field instead of a class name. The format would be one of

     'plain'  - corresponds to CryptsetupEncryptor
     'luks'   - corresponds to LukEncryptor

   This would be the preferred approach going forward

 - Nova should issue a warning if it receives a 'provider' class name
that does not correspond to an existing in-tree encryptor class

 - Cinder should re-write class names to the format enum for the built-
in classes - out of tree classnames should be left alone.


In Pike

 - Cinder should continue re-writing class names to enums for in-tree
classes, but reject out of tree class names with fatal error

 - The cinder v3 should have a microversion added to indicate the point
at which 'provider' will be strictly validated against the 'enum'.

 - Nova should raise an error if it receives a 'provider' class name
that does not correspond to an existing in-tree encryptor class


In Qxxx

 - Nova will stop accepting class names from cinder entirely - cinder
should exclusively be reporting the format enum to Nova, rewriting
legacy data if needed.

** Affects: cinder
     Importance: Undecided
         Status: New

** Affects: nova
     Importance: Undecided
         Status: New

** Also affects: cinder
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1639293

Title:
  Cinder encrypted vol connection info include full nova internal class
  name

Status in Cinder:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  When making an API call to Cinder to get the volume encryption
  metadata:

  2016-10-25 05:30:47.048 6699 DEBUG cinderclient.v2.client [req-
  7fe1959f-36f6-4dd6-bf47-f5e550d59530 3fdb4fc839fc44a9a99006d3fb75ac4d
  c6b14fd5fffa48aa8eb869f30c80e409 - - -] REQ: curl -g -i -X GET
  http://192.168.1.13:8776/v2/c6b14fd5fffa48aa8eb869f30c80e409/volumes/9439e922-1051-4d83-87c7-172689ac29da/encryption
  -H "User-Agent: python-cinderclient" -H "Accept: application/json" -H
  "X-Auth-Token: {SHA1}4ff393589c57548e39cca7b5ed99d8a42d1ac7fa"
  _http_log_request /usr/lib/python2.7/site-
  packages/keystoneauth1/session.py:337

  The reply from cinder includes a fully qualified name of a nova
  private class:

  2016-10-25 05:30:47.100 6699 DEBUG cinderclient.v2.client [req-7fe1959f-36f6-4dd6-bf47-f5e550d59530 3fdb4fc839fc44a9a99006d3fb75ac4d c6b14fd5fffa48aa8eb869f30c80e409 - - -] RESP: [200] X-Compute-Request-Id: req-4e32d4e4-3c02-4fdf-8179-7c9825f446e3 Content-Type: application/json Content-Length: 209 X-Openstack-Request-Id: req-4e32d4e4-3c02-4fdf-8179-7c9825f446e3 Date: Tue, 25 Oct 2016 09:30:47 GMT Connection: keep-alive 
  RESP BODY: {"cipher": "aes-xts-plain64", "encryption_key_id": "00000000-0000-0000-0000-000000000000", "provider": "nova.volume.encryptors.cryptsetup.CryptsetupEncryptor", "key_size": 256, "control_location": "front-end"}
   _http_log_response /usr/lib/python2.7/site-packages/keystoneauth1/session.py:366

  
  THis is very bad for a number of reasons

   - If nova renames its classes, existing encryption breaks because the classs names no longer match what cinder is sending
   - It allows out of tree extensions to nova for different encryption impls, which consume Nova private data structures in method calls. THis is against Nova policy - all such other extension points have been deprected, then removed.
   - If nova wants to implement encryption in a different way (eg by delegating to QEMU), then the concept of an encryptor class does not even apply.

  
  This is actually even worse than Cinder merely passing class names across. Cinder in fact exposes this in its public REST API to tenant users, letting tenants specify arbitrary encryptor classname for nova to use:

  http://docs.openstack.org/mitaka/config-reference/block-storage
  /volume-encryption.html

  $ cinder encryption-type-create --cipher aes-xts-plain64 --key_size 512 \
    --control_location front-end LUKS nova.volume.encryptors.luks.LuksEncryptor

  
  The idea of having the tenant user specify arbitrary nova private class names needs to be removed entirely. Instead we should have an enum of encryption *formats*. Any given format may be implemented by Nova in a variety of ways. Nova will look at the format and decide which encryptor class to use (if any), or decide how to configure QEMU natively to use that format.

  For back compat we can't drop use of class names immediately, so we'll
  need a deprecation period.

  In Ocata:

   - Cinder and Nova should allow an encryption format enum to be used
  in the 'provider' field instead of a class name. The format would be
  one of

       'plain'  - corresponds to CryptsetupEncryptor
       'luks'   - corresponds to LukEncryptor

     This would be the preferred approach going forward

   - Nova should issue a warning if it receives a 'provider' class name
  that does not correspond to an existing in-tree encryptor class

   - Cinder should re-write class names to the format enum for the
  built-in classes - out of tree classnames should be left alone.


  In Pike

   - Cinder should continue re-writing class names to enums for in-tree
  classes, but reject out of tree class names with fatal error

   - The cinder v3 should have a microversion added to indicate the
  point at which 'provider' will be strictly validated against the
  'enum'.

   - Nova should raise an error if it receives a 'provider' class name
  that does not correspond to an existing in-tree encryptor class

  
  In Qxxx

   - Nova will stop accepting class names from cinder entirely - cinder
  should exclusively be reporting the format enum to Nova, rewriting
  legacy data if needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1639293/+subscriptions