SOLVED Questions regarding encryption in TrueNAS-12.0-U1

[PhreakShow]

Hey guys.

Sorry if thats the 100th thread about encryption, but I am pretty puzzled right now. I did a search but weirdly it yielded mostly pretty old threads (>1 year).

My plan was: Supermicro A2SDI-H-TF, four 8TB WD red, 32GB RAM and a sata dom. Create one pool, raidz1, have it encrypted. Set a password.
System does a cold boot, someone has to log in and type the password via webinterface. Pool unlocks and the share is accessible.
Tha's actually how I've been doing it for a while, not sure on the version, I suppose it's 11.

My concern is theft. There's lots of work stuff on that NAS, about 6TB and growing.

But it seems I cannot do it like that anymore. I can encrypt it, but the key is stored on the NAS and of course that renders it useless against theft. It helps in discarding the disks, though.
Adding a password is also not possible if I understood the manual correctly. For that I'd have to move the system dataset to a different pool, which is not possible becuase I only have one pool. Also it is not a smart thing to do to put it on a flash drive, at least it says so in the manual.

So what to do? Did I miss something? Do I have to go back to an older version and never run an update again?

 

[Samuel Tai]

When you create the encrypted pool, you could use either a key or a passphrase to unlock. You may have to destroy and recreate your pool to switch from key to passphrase.

 

[PhreakShow]

Thanks for your reply, but during creation of the pool I cannot switch from key to passphrase? At least I didnt see any possible checkbox or dropdown to do so. Only afterwards theres "encryption options" with the mentioned problem of having to move the system dataset.

 

[Samuel Tai]

Notice the arrow on the right by Key? You can select Passphrase after pulling down.

 

[PhreakShow]

That looks differently on my system. I don't have the arrow, just for switching AES algorithms.

 

[Samuel Tai]

Yes, this is in the Encryption Options screen.

 

[PhreakShow]

Ah ok, that's what I meant in the first post. I cannot switch from key to passphrase, because the system tells me there's the system dataset on that pool. But I only have one pool, I cannot move the system dataset anywhere else.

 

[Samuel Tai]

Unfortunately, this is a design limitation with the system dataset, which was introduced in 11.3 and GELI encryption. The system dataset can't wait for a passphrase on boot.

Of course, this only applies to the root dataset on the pool. You can have passphrases on daughter datasets.

 

[PhreakShow]

Any disadvantages if I go back to that version? Why can the system dataset run without a key in that version?

 

[Samuel Tai]

No, you have to go back to 11.2, not 11.3. 11.3 was the first version that had this limitation.

 

[PhreakShow]

Thanks for clarification, that saved me at least one reinstall ;)

Any problems with my plan?

 

[Samuel Tai]

Personally, I would stay at 12, and leave the root of the pool unencrypted for the system dataset. Then the daughter datasets with sensitive data I'd set with passphrases. Daughter datasets that don't need encryption I'd either leave unencrypted or encrypted with keys.

 

[PhreakShow]

Sounds like a nice tip. Just making sure I got that right: I create a normal pool. and add one or more datasets. They work similar to a partition on a single disk? Then I encrypt that new dataset, like I would with a partition. The system dataset is unaffected and if my NAS gets stolen, nothing can be accessed?

 

[Samuel Tai]

Correct.

 

[PhreakShow]

Awesome. You saved me a lot of time, thanks.

 

[winnielinnie]

Check out my posts about using "pseudo-root" datasets. It keeps things more tidy and easier to maintain, as well as manage native ZFS encryption.

Ever since 12.X, I have always used pseudo-roots, and I treat the "real" root as nothing more than a place-holder for the zpool itself. I cover the issue of the .system dataset as well.

Difficulty replicating native ZFS encrypted pool to new pool.

I'm preparing to move a series of datasets residing on one encrypted pool to another pool. This is primarily intended to be a move from a smaller pool of storage to a larger pool of storage, after which point I'll destroy the smaller pool. The source pool, tank, is set up with TrueNAS 12.0-R...

www.truenas.com

Confused by native ZFS encryption, some observations, many questions

I have been playing around with TrueNAS Core 12.0 in a virtual machine, specifically to get a "hands on" feel for native ZFS encryption. Prior to this, I held the following assumptions where GELI and native ZFS encryption differ: GELI encrypts partitions / block devices, which are then used...

www.truenas.com

TrueNAS 12.0 GELI to Full Drive Encryption Migration

Hi everyone, I have some questions about migrating my 11.x GELI encrypted pool to a new 12.x encrypted pool. I played with this a bit, and I know some of the features are not there yet, but want to get some advice and clarify things a bit. For reference I am mostly following this...

www.truenas.com

And you might find this useful to better understand what native ZFS encryption does not protect / hide:

Help moving pool to new disks

I have my original GELI encrypted pool, and the disks are getting old and starting to die on me. With the new ZFS encryption, it seems like a good time to both migrate to bigger disks and the new encryption. The new pool is currently in a second TrueNAS server that I spun up temporarily and is...

www.truenas.com

 

[PhreakShow]

That's a lot to read, but it raised a suspicion that I might not have understood the concept correctly.

I created a single pool, no encryption. I created a new dataset, encrypted with passphrase. On that dataset, I created a share where all my files go to. Share ACL set to full access to everyone, file ACL set according to the user's rights.

In case of hardware problems, what do I have to backup now? With an encrypted pool I'd save my key file. But now that I am using a passphrase, is there anything to backup at all for desaster recovery?

 

[Samuel Tai]

No, with a passphrase, there's no key file to export.

 

[PhreakShow]

Ah so I did get it right. If I have to move to a different hardware to recover from hardware failure, the only thing needed is the passphrase.

 

[winnielinnie]

Ah so I did get it right. If I have to move to a different hardware to recover from hardware failure, the only thing needed is the passphrase.

Yup! Just keep in mind encryption happens on a per-dataset basis. Even if a parent dataset is not encrypted, you can always create a child dataset underneath with encryption (and choose passphrase or keystring/keyfile).

If you want System Dataset (.system) to be encrypted, then the root dataset must be encrypted (with a keystring/keyfile, not a passphrase.) The reason for this is that the .system dataset must be available upon boot with a key that is loaded from the boot pool. How TrueNAS handles this is by inheriting whatever encryption property the "root dataset" has and applying it to .system upon creation / re-location. (This is true for the initial creation of iocage, as well.)

Upon creating a pool for the first time, the option to "enable encryption" is somewhat misleading, as it does not dictate encryption for all datasets in the pool: only the highest-level root dataset. Yet for most users, they simply have the children datasets "inherit" the root dataset's encryption properties.

Again, this is why I use "pseudo-roots". You get more flexibility with dataset management and send/recv replications. The "true root" dataset serves as a shiny place-holder and has no bearing on making backups nor dictating encryption across the board; even if you only ever have just one pseudo-root. (For me, it's main purpose is to have .system and iocage inherit encryption with a keyfile.)