KVM support for luks volmes?

[OpenNebulaProject]

---

Author Name: Laurence Gill (Laurence Gill)
Original Redmine Issue: 5402, https://dev.opennebula.org/issues/5402
Original Date: 2017-09-25

---

Is there any plans to support luks volumes for virtual machines? I have not managed to find any discussions around this on any opennebula mailing lists.

https://libvirt.org/formatstorageencryption.html#StorageEncryptionLuks

I think it would require qemu 2.6:

https://wiki.qemu.org/ChangeLog/2.6#Block_devices_2

...and also libvirt 2.2.0, and I'd guess you need to create a secret on the hypervisor, unless it could be randomly generated if you are creating a empty datablock to install to. Although if you created the volume outside of opennebula I suppose you could pass the parameters through using the raw kvm contextualisation.

Thoughts? Silly idea?

Cheers

[OpenNebulaProject]

---

Original Redmine Comment
Author Name: Laurence Gill (Laurence Gill)
Original Date: 2017-10-03T16:03:48Z

---

I made a bit of progress on this, see
laurencegill@d9ecac7

Tested on debian jessie and you need to install the qemu/libvirt packages from backports to get the encryption support:

apt-get -t jessie-backports install libvirt0
apt-get -t jessie-backports install qemu-kvm qemu-utils qemu-block-extra qemu-system-common qemu-system-x86

Then create the image and import, create the libvirt secret etc, then you can attach the disk and it is decrypted, if it doesn't work you will still see the device as an encrypted luks disk (luksDump)

The question now is how to generate this the libvirt xml at deployment to contain the libvirt xml? I am a bit stuck here, does the LibVirtDriverKVM.cc file need changing, or is there a simpler way to change what is generated in the deployment file when instantiating the VM?

[OpenNebulaProject]

---

Original Redmine Comment
Author Name: Anton Todorov (Anton Todorov)
Original Date: 2017-10-04T07:16:38Z

---

There is an entry in the backlog addressing the option to alter the VM deployment XML before deploy (#4880).

Currently I am patching the vmm/kvm/deploy script to execute a script to edit the deployment XML file before it is passed to libvirt.

Best Regards,
Anton Todorov

[OpenNebulaProject]

---

Original Redmine Comment
Author Name: Laurence Gill (Laurence Gill)
Original Date: 2017-10-07T11:55:50Z

---

On balance, I figured it would be less lines of code to patch the driver:

laurencegill@fa44566

Seems to work, requires some further testing though...

[FlorianHeigl]

Hey Laurence, if you ever see this:
I like this a lot, but what is your view on the actual security, does the passphrase end up visible on the context iso, or is it only visible to the driver?

[laurencegill]

Hey Laurence, if you ever see this:
I like this a lot, but what is your view on the actual security, does the passphrase end up visible on the context iso, or is it only visible to the driver?

The UUID of the secret is referenced in the image attributes, for example as:
LUKS_SECRET = "35cdaa8f-6923-4378-b8bf-1d819b0f03e8",
The passphrase itself is a private libvirt secret. I have the full documentation somewhere...

I was actually going to bump this to see if there is any chance of merging this patch, as I have to manually patch the packages each time we upgrade, so, bump, anybody..?

[laurencegill]

Basically it is these 2 commits:
laurencegill@d9ecac7
laurencegill@fa44566

It seems I did try to get it merged
#528

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. The OpenNebula Dev Team

[laurencegill]

We've been using this in production for 2 years for persistent VMs without any issues. It would be good to have it merged rather than ignored and marked as abandoned.

[cloudweavers]

I strongly support this as well. I think it is a very useful feature, does not interfere in any way - I would be happy to see it merged.

[tinova]

Ok! You speak, we listen.

Bumping this to 5.12 (although this is not a commitment)

[laurencegill]

Do you expect this to make the 5.17.7 release @tinova ? Is there anything I can do to help?

[tinova]

Unfortunately @laurencegill we need to remove this from 5.12 roadmap as it will soon enter feature freeze (it's an LTS release). We will do out best to tackle this for 6.0. If you could check that the PRs can still be applied into master that will help indeed.

[laurencegill]

I think I have fixed the conflicts, but appear to have upset gitcop, presumably with the historical commit messages not confirming to the standard, which are now buried among the commits as I merged upstream. Shall I just create a new PR and remove the old one, and reference the github issue, as this dates back to the Redmine system?