Why are encrypted datasets and zvols not locking on reboot?

[seanthegeek]

I'm doing encryption at the at the dataset and/or zvol level but not at the pool level, so I can have separate keys for different datasets and/or zvols and still decrypt things if needed. I've noticed that after reboot the encrypted datasets and/or zvols remain unlocked, which is the opposite of what I would expect, So I have a few questions:

• Why is this? Did I just stumble on a bug
• Am I required to have an encrypted pool in order for encrypted datasets and/or zvols to lock on reboot?
• What should I do to make sure that my existing data is properly protected?
  • Is my data actually encrypted?
  • Do I need to wipe my drives and readd the data, or do I just need to encrypt the pools and reset the keys for each encrypted dataset and/or zvol?

 

[winnielinnie]

If you don't use a passphrase (i.e, you are using a "keyfile" / HEX string), then this is stored in your boot-pool, in the plain.

This allows for (by design) automatically unlocking the datasets upon boot.

In order to prevent auto-unlocking, you need to use a passphrase instead of a keyfile.

Keep in mind: This is a TrueNAS "design". This is not vanilla ZFS. (They've implemented it like this to prevent users from accidentally having their System Dataset or jails/apps from being inaccessible after booting their system.)

 

[winnielinnie]

• Am I required to have an encrypted pool in order for encrypted datasets and/or zvols to lock on reboot?

There are no encrypted "pools" in ZFS. Only encrypted datasets and zvols. When you think of an encrypted "pool", you're actually referring to an encrypted top-level root dataset.

Some of the limitations, such as "you cannot nest a non-encrypted dataset underneath an encrypted one, are not ZFS limitations. These are being enforced by the TrueNAS middleware to prevent breakage and the incorrect order of "mounts".

• Is my data actually encrypted?

Yes. Inaccessible "at rest". Of course, anyone who has physical access to your server can simply access the data while it is powered on, and if they are savvy, they can grab your keyfile from /data on the boot-pool. If they outright steal your server and/or boot device, they technically can extract the keyfile.

 

[seanthegeek]

Thank you for the detailed explanation. I prefer to keep my keys/passphrases backed up separately, so switching to passphrases and securely storing those suits my needs better.

I overlooked this detail in the documentation:

You can only lock and unlock an encrypted dataset if it is secured with a passphrase instead of a key file. Before locking a dataset, verify that it is not currently in use.