How to pass key to VM with LUKS-encrypted disk?

[elk]

I rent my server from a cloud provider; it is practically certain that after I finish using the server, it will be rented out to somebody else. For this reason I need to encrypt some sensitive data in 10+ of the VMs, so that people renting the server after me cannot access that data.

The VMs themselves are not encrypted and can boot normally. I only encrypt a QEMU disk attached to each VM, set the disk to automount via /etc/fstab and /etc/crypttab and configure the software to store the sensitive data only on that disk.

The problem is that every time I upgrade the VMs and they need to reboot, I must type the key by hand (The proxmox console does not support copy-paste). I know LUKS can use keyfiles, but I don't know how to provide a keyfile to the VMs in such a way that the keyfile is itself encrypted.

Which brings me to the question: How can I make a key or keyfile available to the VMs upon boot, in such a way that:

- I don't need to type it every time a VM reboots
- The key itself is not stored in the plain

(It is OK to type a key or password once when the whole server boots, as long as I don't have to type things when each VM reboots)

Thanks!

 

[Stefan_R]

(It is OK to type a key or password once when the whole server boots, as long as I don't have to type things when each VM reboots)

How about making a seperate partition on the host (can even be in a loop-file or something if it matters) and encrypting that via LUKS? Then, on server boot you unlock that partition once, and store the secret data in VM disks placed on that partition. Just add the encrypted partition (once it's unlocked) into PVE as a directory storage (ext4, xfs, whatever) and put your qcow2 files on there.

Providing a key to a VM is not possible via a standardized method, so you'd have to use some other channel. OTOMH you could use SMBIOS information set by the host before the VM starts, that should then be readable from the guest via a /sys entry somewhere.

 

[elk]

Sounds like a great idea, thanks! I'll try it.

 

[apoc]

One Option would be to create a service which upon Start of the VM pulls the required key from a secure place (let's say a system at your home which you have under control) via SSH/SFTP/SCP, unlocks the drive and then destroys the key on the VM again. To make sure no relicts exist in the filesystem I would fisable swap, create a small tmpfs for temporary storing the key on unlock and destroy that tmpfs after usage again.
Just to give you an idea whats possible

 

[proxmoxrks]

How about making a seperate partition on the host (can even be in a loop-file or something if it matters) and encrypting that via LUKS? Then, on server boot you unlock that partition once, and store the secret data in VM disks placed on that partition. Just add the encrypted partition (once it's unlocked) into PVE as a directory storage (ext4, xfs, whatever) and put your qcow2 files on there.

Do you have a tutorial/wiki/guide for doing it? Thanks.

 

[H4R0]

Proxmox does support copy&paste, you only have to setup a serial terminal and use xtermjs.

You can also use dropbear to do remote unlocking via ssh.

If you are using zfs with raid1 you can live encrypt the whole proxmox host on the fly.

 

[Stefan_R]

Do you have a tutorial/wiki/guide for doing it? Thanks.

Not quite, but it should be fairly straightforward. Something like:

fallocate -l 32G /loopfile # use whatever size and path you want
losetup --find --show /loopfile
# will print /dev/loopN - substitute N as needed
cryptsetup -v --type luks2 --verify-passphrase luksFormat /dev/loopN
cryptsetup open /dev/loopN secret
mkfs -t ext4 /dev/mapper/secret
mkdir -p /mnt/secret
mount /dev/mapper/secret /mnt/secret

then add the following to /etc/pve/storage.cfg

dir: secret
    path /mnt/secret
    content rootdir,images
    is_mountpoint 1

Once created, on second boot just do 'losetup', 'cryptsetup open' and 'mount' steps.

In PVE itself you then have a regular directory storage where you can place qcow2 or raw image files. Note that there is of course a slight performance overhead.

 

[the_sla_wrecker]

How about making a seperate partition on the host (can even be in a loop-file or something if it matters) and encrypting that via LUKS? Then, on server boot you unlock that partition once, and store the secret data in VM disks placed on that partition. Just add the encrypted partition (once it's unlocked) into PVE as a directory storage (ext4, xfs, whatever) and put your qcow2 files on there.

Providing a key to a VM is not possible via a standardized method, so you'd have to use some other channel. OTOMH you could use SMBIOS information set by the host before the VM starts, that should then be readable from the guest via a /sys entry somewhere.

This is the easiest solution and solves a lot of other problems that arise from encrypting the guest, but it also means that if you're backing up the entire vm, you'll also have to secure the entire backup pipeline.