Best Practices - Encrypt entire Pool or specific Datasets?

[begr4trwh436]

Hello together,

I´m new to TrueNAS Scale, but I already read here many threads and the TrueNAS documentation. My TrueNAS Scale server is already installed on a Boot Disk, but without an Storage Pool, I will wait and understand the encryption process, for example my Notebook is with LUKS encrypted, it asks me each boot process to enter a passphrase, no one can read the data on the disk until I unlock LUKS with the passphrase.

When I would create for example the following pool layout, the easiest way would be to encrypt only "high important" projects folder, at dataset level

tank01
- rootdataset
-- media
---- music
---- movies
-- shares
--- smb
--- nfs
-- projects (encrypted)
--- projectA (encrypted)
--- procectB (encrypted)
--- ... (encrypted)

...but maybe, the other should also be encrypted or new directories would be important again

1) How you handle these data and which encryption type keyfile or passphrase would you choose?

2) I read the keyfile will remain on the boot disk, so each server restart will be automatically decrypt the dataset? If it is true, the strong passphrase approach is for my better to decrypt the content manually!

3) The planned RAIDZ2 pool with 6 disks, how would be to look at a specific disk and mount it on external system, to look into the uncrypted data, is it possible (RAW ZFS)?

4) The decision about encrypt the new pool tank01 from beginning is still open, are there any disadvantages/performance problems/Scrub task on encrypted datasets ... ??

Encryption with TrueNAS:
https://www.truenas.com/docs/core/storage/pools/storageencryption/

 

[Arwen]

The choice between keyfile and passphrase depends on why you want data encrypted. Is it for theft of the NAS? Or is it for failed disk returns for warranty replacement? The first is best handled by passphrase. The second case can be either keyfile or passphrase.

Remember, ZFS encryption is at rest only. Whence the dataset(s) are un-locked, any valid network access can read the data.

ZFS encryption occurs at the data level. Certain ZFS structures, like the metadata that describes the encrypted data, remain un-encrypted. This is by design so that pool scrubs and disk replacements can occur on pools with encrypted data, that has not been un-locked.

It is also possible to have ZFS send the encrypted dataset(s) to a remote location, still encrypted, and not un-locked. Meaning you can have remote backups that can be scrubbed, (or disks replaced), but have no access to the encrypted data.

As for encrypting the entire pool, verses a dataset, (or dataset root and it's children), it depends on the purpose of the encryption.

 

[begr4trwh436]

Yes it´s more in case of a theft of the NAS, I also would prefer to generate a long strong passphrase, should be good enough.

About already encrypted backups, should I use manual ZFS replication to an external USB disk?
How can I test this scenario and try to restore the encrypted backups ?

This thread is interessting, some of them entrypted with keyfile at pool level and a specific sub-dataset with passphrase only:
https://www.truenas.com/community/t...drive-encryption-migration.89337/#post-618435
https://www.truenas.com/community/threads/truenas-encryption-and-replication.93490/

 

[winnielinnie]

4) The decision about encrypt the new pool tank01 from beginning is still open, are there any disadvantages/performance problems/Scrub task on encrypted datasets ... ??

You don't encrypt the "pool" with ZFS native encryption. The documentation and tooltips (upon new pool creation) don't explain this succinctly.

When you choose to create an "encrypted pool", it's really just enabling encryption for the root dataset. By default, newly created children underneath will inherit this encryption. But this can be changed when creating a new dataset (by disabling "Encryption" for the newly created child).

Encryption doe not affect scrubs whatsoever. Same performance, same speed. The reason for this is that the scrub compares the encrypted record against its checksum. No need to decrypt anything. (This is why you can run scrubs on pools with locked datasets.)

3) The planned RAIDZ2 pool with 6 disks, how would be to look at a specific disk and mount it on external system, to look into the uncrypted data, is it possible (RAW ZFS)?

As long as the system supports ZFS, which is rather ubiquitous now with most Linux distros, for example. As long as you can attach all the drives that comprise the pool, then you can import the pool and proceed with the command-line to unlock, mount, scrub, etc.

 

[begr4trwh436]

Hi, yesterday I played with a new test pool, I created an mirror of 2 disks with encryption at top level (only keyfile)
Within the pool I created a dataset "rootdataset" which I unchecked the encryption and set to passphrase, so each child dataset will be encrypted by passphrase. For testing purpose I added a NFS share dataset, created a file:

pool1 (keybased encryption)
- rootdataset (passphrase encryption)
--- share (passphrase encryption)
---- nfs (passphrase encryption)
---- smb (passphrase encryption)

After that I restartet the server, in the storage pool, the pool1 was already unlocked (keybased) and my rootdataset was fine encrypted, that´s what I expected.

1) What in general, the keybased pool1 encrypts, only the names of my subdatasets or more?
2) Where is the keyfile on bootdisk stored under? Could I delete it, to prevent auto-unlocks?
3) When the keyfile is not available on boot, it would be a manual unlock process, should the keybased encryption on top level enough instead with the second passphrase encryption?

 

[winnielinnie]

1) What in general, the keybased pool1 encrypts, only the names of my subdatasets or more?

ZFS encryption does not hide/encrypt/obfuscate the names of datasets and snapshots. So don't use identifiable or sensitive dataset/snapshot names.

2) Where is the keyfile on bootdisk stored under? Could I delete it, to prevent auto-unlocks?

Don't do this. TrueNAS is designed to auto-unlock keyfile protected top-level root datasets. The reason for this is if you have the System Dataset on that particular pool. I still think it's not the best method they chose, but deleting things might break your system and operation. (It's inside the database file under /data)

3) When the keyfile is not available on boot, it would be a manual unlock process, should the keybased encryption on top level enough instead with the second passphrase encryption?

I don't understand this question. Maybe there's a typo?

Either way, make sure you backup the keyfile somewhere safe, so that if you ever re-install or export your pool, you can still unlock the root dataset.

 

[begr4trwh436]

Hi thanks for clarification, one last point, why should someone enable encryption on "pool level" when creating a new pool instead on some specific child datasets?

For example these 2 options:

1 Option

pool1 (keybased encryption)
- mydata (passphrase encryption)
--- share (passphrase encryption)
--- projects (passphrase encryption)

2 Option

pool1 (no encryption)
- mydata (passphrase encryption)
--- share (passphrase encryption)
--- projects (passphrase encryption)

For me the 1) option have more management overhead, I have to backup both the keyfile + passphrase, the 2) option is more "simpler".
Is there a good reason for 1) option, I not, the 2) option is that I should install in my next step.

 

[begr4trwh436]

Any suggestions/answer for my last question?

 

[winnielinnie]

one last point, why should someone enable encryption on "pool level" when creating a new pool instead on some specific child datasets?

It's not really "pool" level. It's just worded that way (incorrectly) for some reason. It enables encryption on the root dataset upon creation of the pool.

Why would you want that? Well, for TrueNAS there's one reason I can think of:

For the System Dataset and iocage to inherit encryption.

Due to the "appliance nature" of TrueNAS, they do not give you granularity to decide on the encryption options for the System Dataset or iocage dataset. It simply inherits what the root dataset has. Period. If the root dataset is encrypted? They will be encrypted. If the root dataset is not encrypted? They will not be encrypted.

 

[begr4trwh436]

It seems that iocage only exists for TrueNAS Core, but not for TrueNas Scale:
https://www.reddit.com/r/truenas/comments/rocte7/truenas_scale_and_iocage_folder/

 

[winnielinnie]

In this case, it would apply to ix-applications instead of iocage.