diff --git a/specs/untargeted/byok-for-cinder.rst b/specs/untargeted/byok-for-cinder.rst index f29e4b49..138808cb 100644 --- a/specs/untargeted/byok-for-cinder.rst +++ b/specs/untargeted/byok-for-cinder.rst @@ -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` +- `Spec for supporting image encryption in OpenStack`