Volume type not considered when restoring image of encrypted volume

Bug #2061154 reported by Markus Hentsch
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
New
Undecided
Unassigned

Bug Description

# Summary

Restoring an image that was originally created based on an encrypted volume (LUKS) in Cinder, will render the resulting volume unusable when the default volume type does not specify a matching encryption and no applicable volume type is explicitly specified by the user.

# Description

Creating an image of a volume using the "os-volume_upload_image" Cinder API action (or "openstack image create --volume ...") when the volume has a volume type with LUKS encryption, the resulting image will contain the raw LUKS blocks, the corresponding encryption key is cloned in Barbican and referenced in the image metadata.

Once this image is transferred back into a volume by using the Cinder API to create a new volume based on this image (or "openstack volume create --image ..."), the LUKS-encrypted blocks are transferred to the newly created volume, the key cloned again for the volume and attached as "encryption_key_id" to the volume metadata.

However, in case the default volume type in Cinder is set to an unencrypted type (which is the default behavior) and the volume creation command does not explicitly state otherwise, the resulting volume will receive an unencrypted type while still containing the LUKS blocks. This makes the resulting volume unbootable/unreadable by Nova instances because it is not interpreted as LUKS encrypted and mounted as-is.
Any Nova instance attempted to boot from it will be stuck at "No bootable device.".

# How to reproduce

This can be reproduced easily on a DevStack as long as

```
enable_plugin barbican https://opendev.org/openstack/barbican
```

is added to `local.conf` to make the key manager available.

Reproduction steps below:

```
# create a secondary (non-default) volume type that is encrypted
openstack volume type create \
    --property volume_backend_name='lvmdriver-1' \
    --encryption-provider luks \
    --encryption-cipher aes-xts-plain64 \
    --encryption-key-size 256 \
    --encryption-control-location front-end \
    lvmdriver-1-LUKS

# create encrypted volume
openstack volume create \
    --type lvmdriver-1-LUKS --size 1 \
    encrypted-volume

# create backup image of encrypted volume
openstack image create \
    --volume encrypted-volume \
    encrypted-volume-backup

# restore backup image of volume without specifying type
openstack volume create \
    --size 1 --image encrypted-volume-backup \
    restored-volume

# check the type of the restored volume
# (it will be the default type, not the encrypted one)
openstack volume show -f value -c type restored-volume

# try booting a server from it
openstack server create --volume restored-volume ...
```

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.