Add support for the "bring your own keys"
Change-Id: I1b34041cb1000891ed3f0ca85749b02ed6d78593 Signed-off-by: Tobias Wolf <wolf@b1-systems.de>
This commit is contained in:
Tobias Wolf
parent
2ae9ed5e5b
commit
3bb1050ac0
|
|
@ -0,0 +1,124 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=========================================================
|
||||
Support for the "bring your own keys" approach for Cinder
|
||||
=========================================================
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/byok-for-cinder
|
||||
|
||||
Cinder currently lags support the API to create a volume with a predefined (e.g. already stored in Barbican) encryption key. This feature would be useful for use cases where end-users should be enabled to store keys later on used to encrypt volumes.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Encryption keys are currently generated completely transparent for end-users. Most features are already implemented and tested therefore. What's missing is the possibility to use a user defined key, known as "bring your own keys", for encryption. This may be useful for certain legal requirements or specifications to be fulfilled.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
- End users are enabled to manage their own keys
|
||||
- With proper backups in place data can be recovered even if the key is lost at the deployer
|
||||
- With trust in the deployer to have a proper KeyManager setup in place data can be securely deleted at any time with deleting the key and volumes attached
|
||||
- Key management can be enabled with the toolset of the end user in multi cloud use cases
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
- ``/v3/{project_id}/volumes``
|
||||
|
||||
* 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
|
||||
* 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().
|
||||
|
||||
Active/Active HA impact
|
||||
-----------------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
For python-cinderclient a new optional attribute may be added.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Encryption key ID lookup will have no significant impact and is already done if e.g. encrypted snapshots are in use.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
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
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
No new ones
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Similar to encrypted snapshot handling.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
The optional new parameter should be listed.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [1] https://input.scs.community/9FbrLgYbT8KFvZGXLzay6Q
|
||||
.. [2] https://review.opendev.org/q/topic:%22image-encryption%22
|
||||
Loading…
Reference in New Issue