Comment 7 for bug 1793159

There may be a valid use case with some additional work, but it's far from defined here, and would require significantly more work than is suggested here. Let me have a go:

1. The user would like Nova to provide assurance that the instance they create is initialised with an unmodified glance image. The user does not trust actors with access to compute host storage.

I think this is a fundamentally impossible proposition because Nova is a program on local storage. The user has no way to independently verify that their storage is encrypted, or that any checking was performed.

2. The user would like Nova to provide assurance that the instance they create is initialised with an unmodified glance image. The user trusts the system administrator of the compute host, but is concerned about casual (non-premeditated) access to user data, and unauthorised access.

The user trusts that the admin has taken reasonable efforts to make the Nova executable tamper-proof, e.g. by using a system like Tripwire. The user trusts that the admin and/or the admin's organisation, makes it difficult to casually circumvent this protection without detection.

As you alluded to above, the only protection Nova currently provides for ephemeral data at rest is encryption, and that's only supported by the LVM backend. The instance is encrypted using a key stored in Barbican. As mentioned above we're trusting the Nova executable in this scenario, so it's ok that Nova proxies the user's credentials to Barbican as long as it doesn't store either the credentials or fetched key anywhere. Lets declare the security of Barbican explicitly out of scope.

If the host is configured to use flat, qcow2, or unencrypted LVM they have no defence, as anybody with access to modify the image cache can equally access instance storage.

Unfortunately, 'encrypted' LVM as currently implemented is similarly vulnerable. When starting the instance we first created an LV for the disk which will store encrypted data. However, we then create a dm-crypt device which we initialise with the key we obtained from Barbican. This presents an unencrypted block device to the host, which we then present to the instance. Any attacker needs only use the dm-crypt device rather than the underlying device, both of which have the same access. The dm-crypt device is only removed if the instance is deleted, or implicitly if the compute host is rebooted.

We would need to address this issue first before it's worth implementing anything else, and given that LVM encryption is essentially useless we should probably do this anyway if any users believe they are gaining anything from this feature. I believe native qemu encryption for ephemeral devices would help here.

Once we have what we believe to be tamper-proof local storage, I think the only robust way to verify the glance image would be to copy it into the tamper-proof storage, and then verify the contents of the tamper-proof storage.

3. The user would like Nova to provide assurance that the instance they create is initialised with an unmodified glance image. The user trusts the compute host completely, but does not trust NFS storage because of its lack of security and increased attack surface.

This is trivial to implement: document that operators should not configure NFS storage.