Unattended mounting of encrypted ZFS volumes

Hello,
as our number of FreeBSD servers grows, it get quite tedious to reboot them, because we use GELI / ZFS root disk encryption.
So, rebooting takes attended time to enter the passphrase during boot.

I am playing with different ideas for how to migrate to an unattended disc encryption and would like to have to feedback on following idea:

1. A server will have an unencrypted small root partition to boot from.
2. After init initialised the network, a script retrieves an encryption key from an external source and saves it into a file.
3. Now a script can mount all encrypted volumes with the key. This would include /usr/local, where the main software and configuration for this particular machine is installed. All data should be stored in encrypted volumes too.
4. Init should continue with the /usr/local/etc/rc.d scripts to start all additional services

Questions:
a) What is the best way to "inject" my script into the init script sequence?
b) How would you handle /var/log, which I would like to have encrypted to?
c) Overall idea doable or not? Are there simpler ways?

Looking forward for the discussion!

Waldemar
 
If the partition auto-unencrypt during the boot phase unnatended, what is the point of using encryption at all?
 
If the partition auto-unencrypt during the boot phase unnatended, what is the point of using encryption at all?
Allmost all our servers are virtual and provided by a 3rd party. Storage is provided via Ceph (https://ceph.io/en/).
I hope to reduce the exposure to ceph servers by using storage encryption.
We are talking about some terabyte of data.
 
Allmost all our servers are virtual and provided by a 3rd party. Storage is provided via Ceph (https://ceph.io/en/).
I hope to reduce the exposure to ceph servers by using storage encryption.
We are talking about some terabyte of data.
Maybe zfs native encryption can be better for this scenario?
 
If you automatically unencrypt the block storage, then you have no protection against processes running on the machine once it is running. That means the only two protections that are left are: (a) someone physically steals the disks and tries to read them without booting, and (b) you can prevent the data from becoming readable by disabling the key server (the thing you referred to as "from an external source" above), but that will only take effect on the next reboot of the machine. Is that small amount of security worth the effort?

And: That external source key server has to be at least as secure as your system itself. You don't have to divulge here how you are planning to do that, but do you have a good plan for that?
 
If you automatically unencrypt the block storage, then you have no protection against processes running on the machine once it is running. That means the only two protections that are left are: (a) someone physically steals the disks and tries to read them without booting, and (b) you can prevent the data from becoming readable by disabling the key server (the thing you referred to as "from an external source" above), but that will only take effect on the next reboot of the machine. Is that small amount of security worth the effort?
Yes, it is worth the effort. But still thanks for your thoughts!
It is not only physically stealing. Ceph is a network attached storage and not managed by us. Here I see the biggest risk, that information gets leaked.


And: That external source key server has to be at least as secure as your system itself. You don't have to divulge here how you are planning to do that, but do you have a good plan for that?

Maybe "unattended" is the wrong word. It is more of a "tell ansible to reboot" and not having to enter the passphrases by hand.
 
Does anyone know, what a good rcorder dependency declaration would be?

Bash:
# PROVIDE: unencrypted_volumes
# REQUIRE: mountcritremote cleanvar ldconfig
# BEFORE:  SERVERS
 
first I will suggest to use GELI - performance is much better when using it! We store GELI keys on various servers encrypted, so each server has a list of servers (and the password for decryption of the key) it could try to contact (via ssh) and fetch the key to a memory disk, decrypts the key and then decrypts the GELI devices and imports the zpools.
 
Back
Top