bec756e040
As described in the launchpad bug [1], backup operations must take care to ensure encryption key ID resources aren't lost, and that restored volumes always have a unique encryption key ID. [1] https://bugs.launchpad.net/cinder/+bug/1745180 This patch adds an 'encryption_key_id' column to the backups table. Now, when a backup is created and the source volume's encryption key is cloned, the cloned key ID is stored in the table. This makes it possible to delete the cloned key ID when the backup is deleted. The code that clones the volume's encryption key has been relocated from the common backup driver layer to the backup manager. The backup manager now has full responsibility for managing encryption key IDs. When restoring a backup of an encrypted volume, the backup manager now does this: 1) If the restored volume's encryption key ID has changed, delete the key ID it had prior to the restore operation. This ensures no key IDs are leaked. 2) If the 'encryption_key_id' field in the backup table is empty, glean the backup's cloned key ID from the backup's "volume base metadata." This helps populate the 'encryption_key_id' column for backup table entries created prior to when the column existed. 3) Re-clone the backup's key ID to ensure the restored volume's key ID is always unique. Closes-Bug: #1745180 Change-Id: I6cadcbf839d146b2fd57d7019f73dce303f9e10b
14 lines
598 B
YAML
14 lines
598 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Fix the way encryption key IDs are managed for encrypted volume backups.
|
|
When creating a backup, the volume's encryption key is cloned and assigned
|
|
a new key ID. The backup's cloned key ID is now stored in the backup
|
|
database so that it can be deleted whenever the backup is deleted.
|
|
|
|
When restoring the backup of an encrypted volume, the destination volume
|
|
is assigned a clone of the backup's encryption key ID. This ensures every
|
|
restored backup has a unique encryption key ID, even when multiple volumes
|
|
have been restored from the same backup.
|
|
|