TrueNAS CORE and Legacy Encryption.

[Apollo]

Importing an encrypted pool in TrueNAS CORE created on earlier version of Freenas will appear as "Legacy Encryption".
What is expected of the "Legacy Encryption" support in the future?
Is it possible to migrate the pool to the new Encryption scheme or does the pool need to be destroyed and recreated with the new encryption?

 

[c77dk]

Importing an encrypted pool in TrueNAS CORE created on earlier version of Freenas will appear as "Legacy Encryption".
What is expected of the "Legacy Encryption" support in the future?
Is it possible to migrate the pool to the new Encryption scheme or does the pool need to be destroyed and recreated with the new encryption?

Had the same thought yesterday - wanted to try out pr. dataset encryption, but the option wasn't there - nuked the pool, and recreated, and now the option is there This was just on a testserver, but have a couple other servers with FDE (RMA reasons), where I'd like to avoid nuking and restoring if possible.

 

[danb35]

Is it possible to migrate the pool to the new Encryption scheme

It should be possible at the CLI in any event, and much of the process has been discussed here. In brief, you'd first remove encryption from the pool (offline a disk, remove the GELI encryption, repartition, resilver into the array, lather, rinse, repeat), upgrade the pool if necessary, then you should be able to enable it. No idea, though, if it will be possible through the GUI.

 

[Ericloewe]

They solve different problems and fundamentally, I don't think it's useful to "migrate" over without heavy admin intervention.

ZFS encryption encrypts datasets. GELI encrypts disks. You could have both and it wouldn't be nonsense (probably overkill for most, though). And you can never encrypt all of a pool with ZFS native encryption. I suspect (though I have not checked) that the top-level dataset cannot be encrypted. And for datasets that are encrypted, things such as dataset names and other properties are not.

As always, blindly applying encryption solves nothing and adds lots of potential trouble. Any sort of automatic migration would really apply mostly to situations where encryption was blindly used because "ooh, look, encryption, let me turn that on!".

 

[Apollo]

It should be possible at the CLI in any event, and much of the process has been discussed here. In brief, you'd first remove encryption from the pool (offline a disk, remove the GELI encryption, repartition, resilver into the array, lather, rinse, repeat), upgrade the pool if necessary, then you should be able to enable it. No idea, though, if it will be possible through the GUI.

That is the messy way to proceed and could potentially take weeks to complete. There is no guarantee the new encryption scheme would apply as dataset encryption only seems to work at pool creation also.

 

[danb35]

That is the messy way to proceed and could potentially take weeks to complete.

Agreed, but it's a possibility.

dataset encryption only seems to work at pool creation also.

Really?

 

[Apollo]

They solve different problems and fundamentally, I don't think it's useful to "migrate" over without heavy admin intervention.

ZFS encryption encrypts datasets. GELI encrypts disks. You could have both and it wouldn't be nonsense (probably overkill for most, though). And you can never encrypt all of a pool with ZFS native encryption. I suspect (though I have not checked) that the top-level dataset cannot be encrypted. And for datasets that are encrypted, things such as dataset names and other properties are not.

As always, blindly applying encryption solves nothing and adds lots of potential trouble. Any sort of automatic migration would really apply mostly to situations where encryption was blindly used because "ooh, look, encryption, let me turn that on!".

When I chose to use encryption on my pools was based on the advantages about system being protected at rest. If a break-in did actually happen, I wouldn't want all my data to be accessible by thieves. I have always weighted the pros and cons following this workflow and back then it made more sense when USB keys and passphrase were used.
Boot SSD's are now hardwired to the system and due to the lack of passphrase for the main pool protection at rest becomes less pertinent.

I have played with the new dataset encryption and it only seem possible upon pool creation.
The benefit I see from using dataset encryption, is the ability of importing the pool as non-encrypted pool and doing so, the pool can still be listed in the drop down list of available pools. This makes sorting/filtering disk a more convenient way.
The drawback as you suggested is that dataset names and pool structure is fully visible. I don't know about files visibility as I haven't explored this area yet.
The top level dataset, ie the pool name, gets the dataset encryption and subsequent dataset can be encrypted inheriting the same key or generate a different one.
The other benefit I saw was during the process of migration by extending the pool by adding an extra Vdev. I didn't need to reapply the encryption key.
I think the new encryption key as its merits.

The "Legacy encryption" scheme is now legacy which means it could be dropped years down the road.

 

[Apollo]

Really?
View attachment 39184

Ok, I didn't try to add a dataset then.
Thanks for pointing it out.

 

[danb35]

I have played with the new dataset encryption and it only seem possible upon pool creation.

I think I demonstrated above that this is incorrect. The pool is not encrypted. But when creating a new dataset, I have the option to encrypt it. Now, I'd expect that a pool created under 11.3 or older would need to be upgraded (I haven't tested that scenario), but it certainly appears that it's possible to add an encrypted dataset to a pool that isn't encrypted.

 

[Ericloewe]

I have played with the new dataset encryption and it only seem possible upon pool creation.

Unless there's a weird FreeNAS limitation, it's definitely possible.
Fake edit: ninja'd

I don't know about files visibility as I haven't explored this area yet.

I'm pretty sure filenames are encrypted, that's not ZFS metadata. I think that encryption never touches the POSIX stuff.

The top level dataset, ie the pool name, gets the dataset encryption and subsequent dataset can be encrypted inheriting the same key or generate a different one.

Does that work? I mean, now that I think about, the fundamental metadata is unencrypted anyway, so it's probably feasible. But I seem to recall a discussion that it wasn't supported, artificially, to avoid some weird scenario I don't remember. Could be imagining things, though.

I haven't looked closely at key management, but I suspect it's less user-hostile than FreeNAS's layer on top of GELI.

 

[danb35]

I suspect it's less user-hostile than FreeNAS's layer on top of GELI.

I think it would be difficult to be otherwise.

 

[Ericloewe]

What better way of not worrying about losing your data to an attacker than to lose it yourself first?

 

[Ofloo]

That depends, important data should be backed up, loosing the data to an attacker or 3rd party is probably worse ! I have data that is useful to me but not critical. You end up backing up the critical data and not the useful. But losing that exact data to a 3rd party might not be what you want. If that makes any sense.

For example I have a backup of my desktop on my nas if I loose the backup that might not be critical. I can always make a new backup. But I wouldn't want that unencrypted backup to fall into the wrong hands. I'd rather see it go to waste. So depends on the data. You should not assume things.

 

[serendipity]

It should be possible at the CLI in any event, and much of the process has been discussed here. In brief, you'd first remove encryption from the pool (offline a disk, remove the GELI encryption, repartition, resilver into the array, lather, rinse, repeat), upgrade the pool if necessary, then you should be able to enable it. No idea, though, if it will be possible through the GUI.

To clarify, you can do even better. You don't need to temporarily decrypt the data.

Namely, you can create the encrypted dataset before removing the GELI encryption. I think you need to use the CLI to create the dataset, but you can then unlock the dataset via the GUI. Next, move the data into the encrypted dataset, for example using rsync. Then only after that, remove the GELI encryption as you suggest, a disk at a time, by replacing the disk with itself and waiting for the resilver.

Thanks for the suggestion — I was successful in using this variant of your approach.

 

[mtthiu]

Simple question, but I could not find any answers to it, yet: Does TrueNAS import encrypted ZFS datasets, that've been created with ZoL 2.0 in a Linux distribution. I used Ubuntu 20.04 LTS, but want to get started with TrueNAS.

 

[Ericloewe]

Yes, of course, that's much of the point of ZFS. Whether the key management interface makes it simple is a question I'll leave for someone who's used it.