As part of the work to enable use of encrypted images/volumes in bug 1406802 , Glance images created by uploading Cinder volumes can now have encryption key identifiers attached to them. These encryption keys need to be deleted when Glance images are deleted -- the fact that this does not happen currently means that these keys will indefinitely consume resources in Barbican and/or an HSM.
Is there an upstream bug for this? If not, could you open one, with detailed instructions about how to hit the bug? From what I understand, one has to use "cinder image-upload" on an encrypted volume, delete the corresponding image, and then use barbican to confirm that it still manages the associated encryption key. I'm not super cinder/barbican fluent, though :) On the Glance side, I think it is just a matter of checking whether the image has a "cinder_encryption_key_id" key in its metadata when deleting it, and then we might be able to call https://github.com/openstack/cinder/blob/b8167a5c3e5952cc52ff8844804b7a5ab36459c8/cinder/volume/utils.py#L925 from Glance, am I right? I'm retargeting to OSP15.
(In reply to Cyril Roelandt from comment #2) > Is there an upstream bug for this? If not, could you open one, with detailed > instructions about how to hit the bug? From what I understand, one has to > use "cinder image-upload" on an encrypted volume, delete the corresponding > image, and then use barbican to confirm that it still manages the associated > encryption key. I'm not super cinder/barbican fluent, though :) > There is no upstream bug tracking this. Yes, this is the right path to test the main part of this. > On the Glance side, I think it is just a matter of checking whether the > image has a "cinder_encryption_key_id" key in its metadata when deleting it, > and then we might be able to call > https://github.com/openstack/cinder/blob/ > b8167a5c3e5952cc52ff8844804b7a5ab36459c8/cinder/volume/utils.py#L925 from > Glance, am I right? > This is most of it (ignoring the step of getting Castellan integrated with Glance), but there may be additional concerns. If Glance can clone an image to another image, it would need to duplicate the encryption key when that operation is performed. Otherwise you end up with the same key used on two images, and when you delete the first image, the second becomes unreadable. > I'm retargeting to OSP15.
This is from the Glance Train release notes: To support the Block Storage service (Cinder) upload-volume-to-image action when the volume is an encrypted volume type, when such an image is deleted, Glance will now contact the OpenStack Key Management service (Barbican) and request it to delete the associated encryption key. Two extra properties must be set on the image for this to work: cinder_encryption_key_id (whose value is the identifier in the OpenStack Key Management service for the encryption key used to encrypt the volume) and cinder_encryption_key_deletion_policy (whose value may be either on_image_deletion or do_not_delete). Please note the following: - An image created by the Block Storage service will have these properties set automatically, with the deletion policy set to on_image_deletion. - The Block Storage service *always* creates a new secret in Barbican when it uploads a volume as an image, keeping a 1-1 relation between each secret stored in the Key Management Service and each image of an encrypted volume stored in Glance. Thus, deleting the Barbican secret *at the time when the image is deleted* will not cause data loss *as long as the secret is not being used for any other purpose.* * The Block Storage service will not use the secret associated with an image for any other purpose. * If you choose to use the Barbican secret identified by the value of cinder_encryption_key_id for any other purpose, you risk data loss. * Manual use of the cinder_encryption_key_* properties is not recommended. - If the cinder_encryption_key_deletion_policy image property is missing or has any value other than on_image_deletion, Glance will not attempt to delete the key whose identifier is the value of cinder_encryption_key_id.
Hi Brian, I have edited the contents of the Doc Text field (below) which will appear in the RHOSP 16.0 GA Relesae Notes. Please review and make any necessary changes. Thanks for your help with this, --Greg PROPOSED DOC TEXT EDIT ---------------------- Previously, when an encrypted Block Storage service (cinder) volume image was deleted, its corresponding key was not deleted. In Red Hat OpenStack Platform 16.0, this issue has been resolved. When the Image service deletes a cinder volume image, it also deletes the key for the image.
Greg, looks good to me!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:0283