openstack
/
cinder-specs
Code Issues Proposed changes
cinder-specs/specs/untargeted/byok-for-cinder.rst

4.2 KiB
Raw Blame History

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