Encrypted volume backups mishandle encryption key IDs

[Alan Bishop]

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.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/537462

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/537462
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=bec756e0401bfbb7a31a0532e4163fcf29126f32
Submitter: Zuul
Branch: master

commit bec756e0401bfbb7a31a0532e4163fcf29126f32
Author: Alan Bishop <email address hidden>
Date: Wed Jan 24 22:07:48 2018 +0000

    Fix how backups handle encryption key IDs

    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

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/cinder 12.0.0.0rc1 release candidate.