Hi guys,
I want to share my solution that I'm using for encrypted storage on PVE. This manual is mainly addressed to beginners, because people who are familiar with ZFS know these things as natural features.
If you are using worlds best virtualization PVE in combination with worlds best storage technology ZFS, this is an easy way to protect your data and run your VMs on encrypted storage. This could be interesting specialy for cloudservers, because they are often running in difficult environments and for this solution, there is for example no need to give a password in early stage of boot. But also on premise it could be helpful. If someone steal your server, for these people it's not possible to access the data of your VMs or to start them. You always need the key to unlock the storage, like a closed door. And at the end, if you have a business and have to fulfill data protection laws, like German GDPR, it's often nessesary to store data of you clients in protected areas.
Please keep in mind: If you are on Linux, you know, there are always many different ways to get the same result. This is one way, it must not be the best but for me it works perfect. People who are using other filesystems could be satisfied with luks.
So let's start. These are the requirements:
- PVE6/7 environment
- ZFS storage
Step 1: Create encrypted filesystem on PVE's default ZFS pool "rpool"
You will be prompted to give a password and to repeat it. Select a secure password with letters, numbers, special characters and with a propper lenght. Please take note, that loss of the password/key will be result in a LOSS OF ANY DATA on the encrypted storage. It's impossible to recover data without the key.
Step 2: Add filesystem as new pool to PVE storage
The new encrypted storage will be displayd as "local-crypt" in the UI and can now be used. If you are on a fresh PVE without any VMs and if you plan to use only encrypted storage, you could delete the default storage "local-zfs". With existing VMs it could be usefull to move them now to the encrypted storage.
Step 3: Mount the encrypted storage after reboots
For the reason, that mount of the encrypted storage needs a password, that cannot (should not) be done during start of the machine. So after every boot you have to mount the storage to start any VM located on this storage
Step 4: Make it easier to mount the storage after reboot
Add this line to ~/.bashrc:
With this alias on the shell, even people who are using PVE with UI but not familar with the Linux shell are be able to easy start the storage after reboot. Simply type "start" at the shell, give password an everything works.
Lets have a look at some advantages and disadvanteges of this solution:
Advantages:
- VMs cannot be startet without knowing the key
- Key is not stored somewhere on the system
- Works "out of the box", no additional packages or products needed
Disadvanteges:
- VM Autostart will not work unless you hurry up to unlock the storage after reboot
- System need manual intervention after power loss
- Data will be lost FOREVER if key will be lost
BTW: You can do this also on PBS to have your backups placed on encrypted storage, even with separately encrypted storage for every PVE.
Please feel free to leave your toughts or recommendation.
Thanks,
Martin
I want to share my solution that I'm using for encrypted storage on PVE. This manual is mainly addressed to beginners, because people who are familiar with ZFS know these things as natural features.
If you are using worlds best virtualization PVE in combination with worlds best storage technology ZFS, this is an easy way to protect your data and run your VMs on encrypted storage. This could be interesting specialy for cloudservers, because they are often running in difficult environments and for this solution, there is for example no need to give a password in early stage of boot. But also on premise it could be helpful. If someone steal your server, for these people it's not possible to access the data of your VMs or to start them. You always need the key to unlock the storage, like a closed door. And at the end, if you have a business and have to fulfill data protection laws, like German GDPR, it's often nessesary to store data of you clients in protected areas.
Please keep in mind: If you are on Linux, you know, there are always many different ways to get the same result. This is one way, it must not be the best but for me it works perfect. People who are using other filesystems could be satisfied with luks.
So let's start. These are the requirements:
- PVE6/7 environment
- ZFS storage
Step 1: Create encrypted filesystem on PVE's default ZFS pool "rpool"
zfs create -o encryption=on -o keyformat=passphrase rpool/encrypted_data
You will be prompted to give a password and to repeat it. Select a secure password with letters, numbers, special characters and with a propper lenght. Please take note, that loss of the password/key will be result in a LOSS OF ANY DATA on the encrypted storage. It's impossible to recover data without the key.
Step 2: Add filesystem as new pool to PVE storage
pvesm add zfspool local-crypt -pool rpool/encrypted_data
The new encrypted storage will be displayd as "local-crypt" in the UI and can now be used. If you are on a fresh PVE without any VMs and if you plan to use only encrypted storage, you could delete the default storage "local-zfs". With existing VMs it could be usefull to move them now to the encrypted storage.
Step 3: Mount the encrypted storage after reboots
zfs mount -l rpool/encrypted_data
For the reason, that mount of the encrypted storage needs a password, that cannot (should not) be done during start of the machine. So after every boot you have to mount the storage to start any VM located on this storage
Step 4: Make it easier to mount the storage after reboot
Add this line to ~/.bashrc:
alias start="zfs mount -l rpool/encrypted_data"
With this alias on the shell, even people who are using PVE with UI but not familar with the Linux shell are be able to easy start the storage after reboot. Simply type "start" at the shell, give password an everything works.
Lets have a look at some advantages and disadvanteges of this solution:
Advantages:
- VMs cannot be startet without knowing the key
- Key is not stored somewhere on the system
- Works "out of the box", no additional packages or products needed
Disadvanteges:
- VM Autostart will not work unless you hurry up to unlock the storage after reboot
- System need manual intervention after power loss
- Data will be lost FOREVER if key will be lost
BTW: You can do this also on PBS to have your backups placed on encrypted storage, even with separately encrypted storage for every PVE.
Please feel free to leave your toughts or recommendation.
Thanks,
Martin
Last edited: