Given a very simple infrastructure - a single machine running a hypervisor(Proxmox if it matters), I want to achieve a good data protection against the hardware being stolen.
Let's say there are various VM's running on the hypervisor - most of those don't need to be encrypted, but for the NAS/personal cloud ones I want the data to be safe if the hardware gets stolen.
I would like to get some ideas on the best practices to handle such scenarios. I've thought about it a bit and came up with several approaches from which I have hard time choosing which is optimal and if there are any problems/risks that I'm overlooking.
Full disk encryption of the host
This is out of the question, because the hardware is often left unattended, so it has to be able to recover in a reboot on itself and some of the VM's(CCTV, web servers, etc) need to start without intervention
Encrypting the disk/partition containing the VM volumes on the host
An easy approach would be encrypting a disk that would hold the sensitive VM volumes.
What I like in this approach is I can group all qcow2 volumes I need into a storage bucket that's locked on startup and I manually unlock it via SSH or a custom API.
What I don't like is this has to live on the Proxmox host and I'd like to keep it as clean as possible. Also a downside is that I can't boot a VM without some of its vm disks available(I hoped it would behave just like trying to boot a real computer with a harddisk removed). This would basically mean I can't have the NAS boot without the sensitive disk attached.
There is a way to programmatically detach the disk from the vm, and attach it on unlocking, but again I would like to keep the Proxmox side as clean as possible.
A third potential drawback are backups, since the actual qcows and FS's inside are not encrypted, so I have to take additional care of encrypting the backup itself.
Delegate all encryption to the VM guests
The cool thing here is each VM can handle the encryption on its own - like a VM that I want fully encrypted, I can turn on full disk encryption on the system drive and need to connect via VNC/console to unlock it on boot, OR, I can have a single partition/vm disk encrypted on the guest side(for example the NAS storage drives I need to be safe).
On the downside I need to unlock each VM separately, also this brings the responsibility to maintain/backup the luks headers for each partition encrypted, and I'm concerned if so many levels of abstraction of the storage could become fragile - in this case it would be the FS of the host, a qcow2 storage on top of it, then inside - a virtual disk, then on top of it - luks/dm-crypt, then the fs and partitions themselves.
The huge upside is this would be completely irrelevant for the host so backups will have the guest fs's encrypted, no modifications of the host, and most flexibility on the VM's. I think sounds the most convenient and "compatible" way of doing it, treating the VM's as standalone machines. My only worry here is this many levels of abstraction - am I paranoid?
Encrypted hdd passthrough
I'm currently using this approach where the sensitive storage is a fully encrypted separate disk, that's passed-through into the NAS system. Although this feel safest, as I don't have additional layers of abstraction, this causes me some pains in terms of automatic backups and Proxmox not being particularly friendly to passed-through disks - it doesn't count them as standard storage, doesn't expose any UI for maintaining them, etc.
The good side is, it's a completely standard data drive that I can just unplug, put into another PC and decrypt/read.
So, from an elegance standpoint I think I'm leaning towards option 3 - treating each VM as a standalone PC that bears the responsibility for its encryption - whether it's the whole disk encryption for the VM, or encrypting a single partition/virtual disk inside.
I have several concerns which I have no idea how valid or sensible are:
- Is there any "safe limit" to the size of a qcow2 file? Like, is there any downside in having a storage virtual disk in a qcow2 format with a size of, say, 1TB?
- Is there any real additional in having these additional abstraction levels in storage in terms of hidden data corruption, etc? I suppose the ordeal of data recovery of such a filesystem would be hellish, so reliable backups become even more paramount?
- Is there a "standard" way of handling storage dependencies in services running under Linux? Meaning, let's say I let the NAS boot, but its backup storage isn't unlocked. A separate VM that depends on this storage via NFS won't be able to mount it, so if whatever service uses the 2nd VM, it would start writing in the mount point. I surely can script my way out of this, but I don't want to rediscover the wheel if good practices are already laid out.
Any ideas or advice are very welcome.