Comment 8 for bug 1793159

Okay, let's summarize our proposed use case to get a better picture of the scenario:

The cloud provider has set "CONF.ephemeral_storage_encryption.enabled=True", "CONF.images_type=lvm" and setup the related options accordingly. As a result, Nova VM instances that aren't booted from a volume will use encrypted LVM volumes as their boot disk, located locally on the compute host.

Futhermore, the cloud provider wants to support VM migration scenarios and sets "CONF.state_path" to a NFS directory shared between a group of compute hosts that will support migration. "CONF.instances_path" is set to its default value ("$state_path/instances") to support this scenario. As a result, the image cache (which is always a subdirectory of "CONF.instances_path") is not a local source from the compute host's perspective anymore.

Finally, the cloud provider has set "CONF.verify_glance_signatures=True", so that images downloaded from Glance have their signature checked using a certificate that is retrieved on-demand from Barbican.

Given this environment, whenever an instance is created from an image, two major cases come into play:

A) The image is not cached on the corresponding compute host. It is downloaded into Nova's image cache from Glance. During this, the image signature is verified. An encrypted LVM volume is created. Finally, the image is transformed (essentially copied) into the encrypted LVM volume, which then acts as the boot block storage device for the VM instance.

B) The image is cached on the corresponding compute host. An encrypted LVM volume is created. The desired image located in the cache is directly transformed (copied) into the encrypted LVM volume, which then acts as the boot block storage device for the VM instance.

The problem in case B is that the signature is not checked again. When an image is transformed into an instance it should get its signature verified if the image originates from an external source (not located on the compute host itself). In the environment described above, both the Glance server as well as the image cache (shared NFS) resemble external sources. Both of the sources might have been tampered with even if the compute host itself is trusted.

Regarding the points of performance / computational costs:

As with many other security-related options (e.g. ephemeral storage encryption, signature checks), the behavior of additional signature verification for the image cache could be introduced as an optional mechanism that has to be explicitly actived via a setting in nova.conf

Furthermore, when the transformation from image to instance disk happens, the image has to be computed completely anyway. Based on this, another possibility could be to not complement the existing signature verification (case A, image -> cache) with an additional verification (case B, cache -> instance) but to move the signature verification mechanism closer to the transformation process altogether, so it is used uniformly for both cases at the same point in the process (image data -> instance)