Bug 1801255

We have to take this seriously because of possible data loss, but the end user would have to boot an instance that is 'active' but unusable, and then do the image-create action on that instance.

Brief backstory: when a Cinder encrypted volume is uploaded as an image to Glance, a secret in barbican specific to that image is created.  Beginning with Train, the image metadata "cinder_encryption_key_deletion_policy": "on_image_deletion" is also put on such an image.  On image deletion, if Glance finds such metadata on an image, it will try to delete the barbican secret for the image.

The problem: direct boot of an instance from an image I-1 created from an encrypted volume is *not supported* by Nova.  (The workflow is that you use the image to boot an instance from a volume.)  However, if you do try a direct boot of I-1, Nova creates an instance S-1 in 'active' status (though it is unusable).  If a user does the Nova image-create action on S-1, a new image I-2 will be created *and* it will inherit the image properties from I-1, including the cinder_encryption_key_id and cinder_encryption_key_deletion_policy metadata.  Since I-2 has a reference to the barbican secret for I-1, when I-2 is deleted, the secret for I-1 will be deleted, thereby making it impossible to decrypt I-1.


Version-Release number of selected component (if applicable): 16 (Train)
This does not occur in earlier versions.


How reproducible: always


Steps to Reproduce:
1. in cinder: create volume V-1 of an encrypted volume-type
2. in cinder: use the upload-volume-to-image action to create I-1 in glance
3. in nova: boot an instance S-1 from I-1
4. in nova: do the image-create action on S-1, yielding image I-2 in glance
5. in glance: delete image I-2


Actual results:
The barbican secret whose uuid is contained in the cinder_encryption_key_id image property of image I-1 is deleted.


Expected results:
The barbican secret for image I-1 should *not* be deleted.


Additional info:
Nova has a non_inheritable_image_properties configuration option.  The 'cinder_encryption_key_*' properties should be added to this list, and then this situation will not occur.