Support for the "bring your own keys" approach for Cinder
Bug #2051108 reported by
NotTheEvilOne
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
New
|
Undecided
|
Unassigned | ||
OpenStack Compute (nova) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Description
===========
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.
Work flow would be as follow:
1. End user creates a new key and stores it in OpenStack Barbican
2. User requests a new volume with volume type "LUKS" and gives an "encryption_
3. Internally the key is copied (like in volume_
We've drafted a basic approach what we think needs to be changed. [1]
Here's the summary: volume/ api.py to accept an encryption key ID. The encryption key should be stored in the configured KeyManager (usually Barbican) beforehand to keep changes minimal and maintainable. Based on feedback of the OpenStack community an alternative would be to provide and store the key right away on create. n_key() of /cinder/ volume/ volume_ utils.py must be used to ensure keys can be deleted when the volume is deleted.
- Update /cinder/
- clone_encryptio
[1] https:/ /input. scs.community/ 9FbrLgYbT8KFvZG XLzay6Q? view#OpenStack