# Unattended mounting of encrypted ZFS volumes



## wdick (Oct 28, 2021)

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


----------



## Menelkir (Oct 28, 2021)

If the partition auto-unencrypt during the boot phase unnatended, what is the point of using encryption at all?


----------



## wdick (Oct 28, 2021)

> 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.


----------



## Menelkir (Oct 28, 2021)

wdick said:


> 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?


----------



## ralphbsz (Oct 29, 2021)

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?


----------



## wdick (Oct 29, 2021)

ralphbsz said:


> 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.




ralphbsz said:


> 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.


----------



## wdick (Oct 29, 2021)

Menelkir said:


> Maybe zfs native encryption can be better for this scenario?


Yes, looks simpler to use than GELI / ZFS.


----------



## wdick (Oct 29, 2021)

Does anyone know, what a good `rcorder` dependency declaration would be?


```
# PROVIDE: unencrypted_volumes
# REQUIRE: mountcritremote cleanvar ldconfig
# BEFORE:  SERVERS
```


----------



## rootbert (Oct 29, 2021)

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.


----------



## grahamperrin@ (Oct 30, 2021)

FreeBSD bug 256483 – zfs doesn't automount encrypted datasets

– fixed in _main_ i.e. FreeBSD 14.0-CURRENT and _stable/13_ but not yet _RELEASE_.

<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256483#c8>



> … I'm confused by the absence of zfskeys:  …


----------

