yahoo-eng-team team mailing list archive

[Brian Rosmaita <rosmaita.fossdev@xxxxxxxxx>]

Public bug reported:

Description
===========

When an instance is booted from a image created from an encrypted Cinder
volume and several images are created from that instance, deleting any
one of these images will render the remaining images unusable.


The scenario
============

1. User creates a volume V-1 of an encrypted type in Cinder; Cinder
automatically stores the encryption key in Barbican with key_id c-1.

2. User uploads this volume as an image to Glance as I-1.  Cinder stores the encryption key in Barbican with key_id c-2 and puts the metadata
  cinder_encryption_key_id: c-2
on the image.

The idea is to preserve a 1-1 relation between key_ids and resources so that when a resource is deleted, its key in Barbican can also be deleted with no potential for data loss.  This prevents cruft from accumulating in the user's Barbican account.  In Train, this deletion-from-Barbican process has been automated; if the metadata
  cinder_encryption_key_deletion_policy: on_image_deletion
is present on the image, Glance will delete the key from Barbican when the image is deleted.  Beginning with Train, Cinder puts the deletion_policy metadata on all volumes uploaded as images to Glance.

3. User boots an instance from image I-1.  Nova will store all the image
metadata from the image.

4. User does the createImage action on the instance.  Nova creates an image I-2 and copies over the image metadata, putting
  cinder_encryption_key_id: c-2
  cinder_encryption_key_deletion_policy: on_image_deletion
on the image.

5. If the user deletes I-2, key c-2 will be deleted from Barbican,
thereby rendering image I-1 unusable.  Similarly, if the user has
created a bunch of images from the instance, deleting one of them will
render all the remainder useless.

NOTE: if the user creates a volume from image I-1, Cinder will create a
new Barbican secret for the resulting volume.  So deleting I-1 (and
hence key c-2) won't affect the usability of any volumes created from
it.

This bug has been around for a while, but it required the user to
manually delete the Barbican secret that multiple images depend on.  The
Cinder/Glance change in Train to automate the process makes this
scenario much more likely to happen.

The immediate workaround is to add
'cinder_encryption_key_deletion_policy' to the
non_inheritable_image_properties list in nova.conf.

The long term solution is for Nova to clone the encryption key in
Barbican so that Nova always puts a unique key_id on the created image.

** Affects: nova
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1852106

Title:
  Possible data loss from createImage action

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===========

  When an instance is booted from a image created from an encrypted
  Cinder volume and several images are created from that instance,
  deleting any one of these images will render the remaining images
  unusable.

  
  The scenario
  ============

  1. User creates a volume V-1 of an encrypted type in Cinder; Cinder
  automatically stores the encryption key in Barbican with key_id c-1.

  2. User uploads this volume as an image to Glance as I-1.  Cinder stores the encryption key in Barbican with key_id c-2 and puts the metadata
    cinder_encryption_key_id: c-2
  on the image.

  The idea is to preserve a 1-1 relation between key_ids and resources so that when a resource is deleted, its key in Barbican can also be deleted with no potential for data loss.  This prevents cruft from accumulating in the user's Barbican account.  In Train, this deletion-from-Barbican process has been automated; if the metadata
    cinder_encryption_key_deletion_policy: on_image_deletion
  is present on the image, Glance will delete the key from Barbican when the image is deleted.  Beginning with Train, Cinder puts the deletion_policy metadata on all volumes uploaded as images to Glance.

  3. User boots an instance from image I-1.  Nova will store all the
  image metadata from the image.

  4. User does the createImage action on the instance.  Nova creates an image I-2 and copies over the image metadata, putting
    cinder_encryption_key_id: c-2
    cinder_encryption_key_deletion_policy: on_image_deletion
  on the image.

  5. If the user deletes I-2, key c-2 will be deleted from Barbican,
  thereby rendering image I-1 unusable.  Similarly, if the user has
  created a bunch of images from the instance, deleting one of them will
  render all the remainder useless.

  NOTE: if the user creates a volume from image I-1, Cinder will create
  a new Barbican secret for the resulting volume.  So deleting I-1 (and
  hence key c-2) won't affect the usability of any volumes created from
  it.

  This bug has been around for a while, but it required the user to
  manually delete the Barbican secret that multiple images depend on.
  The Cinder/Glance change in Train to automate the process makes this
  scenario much more likely to happen.

  The immediate workaround is to add
  'cinder_encryption_key_deletion_policy' to the
  non_inheritable_image_properties list in nova.conf.

  The long term solution is for Nova to clone the encryption key in
  Barbican so that Nova always puts a unique key_id on the created
  image.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1852106/+subscriptions