Support transferring encrypted volumes

Registered by Alan Bishop

Currently, cinder does not support transferring an encrypted volume due to the need to transfer its (and its snapshots) encryption key. This blueprint proposes an enhancement to transfer the key along with the volume and its snapshots.

The mechanism relies on the ability to create a copy of an encryption key, and store it as a barbican secret that is owned by another entity. The process would work like this:

1. User X initiates the transfer

- Using the X's context, fetch the key using the volume's encryption_key_id
- Using cinder's service credentials, create a new barbican secret with the same key (i.e. the actual secret)
- Update the volume (and its snapshots) DB to store the new encryption_key_id that is owned by the cinder service
- Using X's context, delete the original barbican secret (the original encryption_key_id)

2. User Y accepts the transfer

- Fetch the key for the encryption_key_id using cinder's service credentials
- Create a copy of the key, and store it using Y's context
- Update the volume (and its snapshots) DB to store Y's new encryption_key_id
- Use the cinder service credentials to delete the barbican secret that it previously created

3. User X deletes (cancels) the transfer

Conceptually this is identical to accepting a transfer, except the recipient is X. A new encryption_key_id is generated that is owned by X, and the intermediate one owned by the cinder service is deleted.

A new microversion would be created for the feature, but otherwise there would be NO change to the volume-transfer API requests or responses.

Blueprint information

Rajat Dhasmana
Alan Bishop
Alan Bishop
Series goal:
Accepted for zed
Needs Code Review
Milestone target:
milestone icon zed-3
Started by
Alan Bishop

Related branches



Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.