VolumeTransfer

Launchpad Cinder blueprint: volume-transfer
Created: 01 March 2013
Last updated: 01 March 2013
Drafter: Dermot Tynan Liam Kelleher
Contributor: Dermot Tynan Liam Kelleher

Rationale

There is a need to support transferring of Cinder Volumes from one customer to another. An example might be where a specialty consultancy produces bespoke bootable volumes or volumes with large data sets. Once the volume is created, it can be transferred to the end customer using this process. Similarly, for bulk import of data to the cloud, the data ingress system can create a new cinder volume, copy the data from the physical device, and then transfer ownership of the device to the end-user.

This blueprint describes a mechanism for securely transferring a cinder volume from one cloud customer to another.

Use cases

The following examples define how a Cinder Volume Transfer mechanism would facilitate specific customer types. This is not an exhaustive list of use cases and merely serves as a reference of some of the more common cases.

Bespoke or custom volumes

A company produces a bespoke dataset on behalf of their clients. This could involve large amounts of processed marketing information, or analysis of customer data. It could also involve a custom, bootable volume which has client-specific data in the configuration.
Once the volume is created, a transfer-allow record and authorization code is prepared.
The volume ID and authorization code are securely delivered to the end-client, by the company.
The end client uses both the volume ID and the authorization code to claim their volume.
The volume now belongs to the end client, who can attach, detach and delete the volume as required.

Volume repair service

A cloud customer has damaged their virtual disk, in some way – perhaps by accidentally deleting files, or by corrupting elements of the file system.
They contract with a third-party firm to repair the volume or restore the files.
The customer creates a transfer record and pass the volume ID and authorization code to the repair agency.
The repair agency claims the volume, and begins the repair process.
On completion, they create a transfer record and send the new authorization code back to the customer.
The original cloud customer reclaims their repaired volume.

Bulk data import service

A cloud customer has a large data set which they would like to migrate to the cloud.
They ship a physical drive to an ingress point provided by the cloud facility.
The operator receives the drive and creates a matching virtual disk.
The data is copied from the physical drive to the virtual one, and the drive returned to the customer.
The operator creates a transfer record and securely forwards the authorization code and volume ID to the cloud customer, who claims their drive.

Design

The process requires that both parties agree to the operation and can securely exchange an authorization key between both parties.

The volume donor initiates the process by requesting a volume transfer authorization code for a specific volume. The volume must be in an ‘available’ state or the request will be denied. As long as the transfer request is valid in the database (in other words, it hasn’t either been deleted or expired), the volume will be placed in an ‘awaiting transfer’ state.

The transfer table in the Cinder database is used to maintain all transfer requests. The request includes the volume_id to identify the particular volume, a 128-bit “salt” code, and a 160-bit SHA-1 hash value.

The new API command to create a transfer record first verifies that the volume is owned by the donor. It produces the 128-bit key salt, and also computes a 512-bit random key with the appropriate entropy. The salt and the key are combined, passed through the SHA-1 process, and the result saved in the database. The key is also returned to the user as a character string. The key is not saved in the database or in log files. If lost, it cannot be recovered.

It is the responsibility of the volume donor to protect the privacy of the key, and to ensure that only the volume recipient is given access to it. The recipient can claim the drive, provided they have the volume ID and the authorization key. They run a similar command via the API to specify both the ID and the key. If there is an undeleted entry in the transfer table for the specified volume, and the expiry date of the entry has not passed, then the salt is combined once again with the specified key, and passed through the same one-way SHA-1 process. If the result compares with that stored in the database, the user_id and the project_id for the volume are updated to those of the API caller.

Other mechanisms were considered, such as retaining the recipient user_id and project_id in the transfer table, or a mechanism whereby the recipient first requested the volume. However, the security of the volume and of the transfer can only be assured by using a shared secret. A new table needs to be created in the Cinder database, with the name volume_transfers with the following structure:

id	Varchar(36)
volume_id	Varchar(36)
salt	Varchar(255)
crypt_hash	Varchar(255)
expiry	DateTime

The volume donor will be allowed to specify an expiry for the transfer record. The default might be 14 days, for example.

The donor can also delete the transfer record for the specified volume at any time, and without needing to specify the authorization code. In this way, if the key is lost or compromised, the donor can remove the transfer request.

The quota system is not directly affected by this blueprint. During the process of accepting a transfer, the quota is checked in a similar way to when a new volume is created. The transfer will be refused if the recipient does not have sufficient quota. Overall, the mechanism for receiving a volume transfer is quite similar to that of volume creation, except that the volume already exists. Elements such as quota checking and the like are performed in a similar manner.

Once a volume has been transferred to a new owner, the volume is indistinguishable from volumes which were created conventionally. It can be deleted, attached, used to generate a snapshot, or transferred away, just like any other volume.

Migration

As this is a new feature, with a new database table, there are no migration issues or changes to existing tables.

Unresolved issues

The system is equally applicable to snapshots, and the database schema as well as the API interface is quite similar. However, this document has deferred the question of snapshots to a later blueprint, in order to reduce the initial complexity.