Encrypted volume backups mishandle encryption key IDs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
Undecided
|
Alan Bishop |
Bug Description
When creating a backup of an encrypted volume, the encryption key is cloned and the cloned key ID is saved in the backup data. However, when the backup is deleted, the cloned key ID isn't being deleted. While this is not a problem when using the legacy ConfKeyManager, it "loses" the key ID (leaks a resource) when using real key managers such as Barbican. The cloned key ID needs to be saved in the backup database so that it can be deleted when the backup is deleted.
Other problems occur when restoring the backup of an encrypted volume. The restored volume's encryption key ID is overwritten by the backup's cloned key ID. The first problem is the restored volume's original encryption key ID (the one it had prior to the restore operation) is not deleted. As described above, this can cause a resource to be leaked. A second problem occurs if multiple volumes are restored from the same backup. Every one of these restored volumes will have the same encryption key ID (the backup's cloned key ID). This is a problem because deleting one volume will delete the encryption key ID for all volumes using that key ID. When restoring a backup, the target volume's orignal key ID must be deleted, and a unique key ID generated from the backup's key ID.
Changed in cinder: | |
assignee: | nobody → Alan Bishop (alan-bishop) |
Fix proposed to branch: master /review. openstack. org/537462
Review: https:/