Small cleanups

Change-Id: I3b70231cd46e3161920216efcfb0c0cc4e3d8b97
Signed-off-by: Tobias Wolf <wolf@b1-systems.de>
This commit is contained in:
Tobias Wolf 2024-02-12 07:43:48 +01:00
parent 3bb1050ac0
commit bc4e38fc9e
1 changed files with 9 additions and 9 deletions

View File

@ -31,12 +31,12 @@ Proposed change
Most peaces are already in place and do not to be changed for that feature to be implemented. The KeyManager implementation holds the key provided by the end user.
- The most visible change is to be able to provide an encryption key ID to create volume.
- cinder.volume.volume_utils.clone_encryption_key() must be used to ensure keys can be deleted when the volume is deleted
- ``cinder.volume.volume_utils.clone_encryption_key()`` must be used to ensure keys can be deleted when the volume is deleted
Alternatives
------------
The API could be extended to create volumes with given key data. From the developer side difficulties are seen in how keys are managed internally (that's why clone_encryption_key() is used for snapshot based volumes). From the deployers perspective the KeyManager API is hidden from the end user and maybe for specific implementations logs are less detailed if called internally from Cinder.
The API could be extended to create volumes with given key data. From the developer side difficulties are seen in how keys are managed internally (that's why ``clone_encryption_key()`` is used for snapshot based volumes). From the deployers perspective the KeyManager API is hidden from the end user and maybe for specific implementations logs are less detailed if called internally from Cinder.
Data model impact
-----------------
@ -50,13 +50,13 @@ REST API impact
* Create a volume: POST
* Normal http response code(s): 202
* New optional parameter encryption_key_id indicates which encryption key ID from the KeyManager implementation should be used
* New optional ``parameter encryption_key_id`` indicates which encryption key ID from the KeyManager implementation should be used
* Maybe a new use of response code 409 may be needed if e.g. a encrypted snapshot volume should be copied with a different key
Security impact
---------------
No direct security impact changes are connected with the proposed change. For the alternative solution sensitive encryption keys are handled by .Create().
No direct security impact changes are connected with the proposed change. For the alternative solution sensitive encryption keys are handled by ``.Create()``.
Active/Active HA impact
-----------------------
@ -71,7 +71,7 @@ None
Other end user impact
---------------------
For python-cinderclient a new optional attribute may be added.
For ``python-cinderclient`` a new optional attribute may be added.
Performance Impact
------------------
@ -99,8 +99,8 @@ nteo
Work Items
----------
- Update /cinder/volume/api.py to accept an encryption key ID. The encryption key ID should be stored in the configured KeyManager (usually Barbican). Based on feedback of the OpenStack community an alternative would be to provide and store the key right away on create.
- clone_encryption_key() of /cinder/volume/volume_utils.py must be used to ensure keys can be deleted when the volume is deleted
- Update ``/cinder/volume/api.py`` to accept an encryption key ID. The encryption key ID should be stored in the configured KeyManager (usually Barbican). Based on feedback of the OpenStack community an alternative would be to provide and store the key right away on create.
- ``clone_encryption_key()`` of ``/cinder/volume/volume_utils.py`` must be used to ensure keys can be deleted when the volume is deleted
Dependencies
============
@ -120,5 +120,5 @@ The optional new parameter should be listed.
References
==========
.. [1] https://input.scs.community/9FbrLgYbT8KFvZGXLzay6Q
.. [2] https://review.opendev.org/q/topic:%22image-encryption%22
- `Original research of encryption features<https://input.scs.community/9FbrLgYbT8KFvZGXLzay6Q>`
- `Spec for supporting image encryption in OpenStack<https://review.opendev.org/q/topic:%22image-encryption%22>`