OpenZFS 2.0 on TrueNAS 12 means no more need for GELI?

[winnielinnie]

I'm trying to understand what I'm reading across forum threads, here and elsewhere, in regards to per dataset encryption via OpenZFS 2.0.

1) Am I correct to assume that beginning with TrueNAS 12 / OpenZFS 2.0, that I can simply create pools without any underlying GELI/encryption, and then later decide to encrypt specific datasets as needed?

2) Would I be able to lock/unlock such datasets using a passphrase only, without a keyfile? (In the same way LUKS allows you to choose a keyfile or a passphrase per slot, and not force you to use a keyfile.) The way GELI is currently implemented on FreeNAS forces you to use a keyfile, even for a pool that contains only data with no jails, no plugins, and no system-dataset.

3) Would encrypting many separate datasets create a lot of CPU overhead as each decryption is a separate process (e.g, I have 8 encrypted datasets, and if data is being accessed through all of them, there will be 8 decryption processes)?

4) Could this get around the issue with the locking/unlocking restrictions for the system-dataset? In other words, even with many encrypted datasets, the system-dataset will have a special protection where it cannot be locked with a passphrase (as it decrypts during boot), even though all the other datasets on the same pool can still be encrypted and locked with a passphrase.

Is there a guide anywhere that explains this new encryption method and how it applies to TrueNAS? I believe there are also some implications for replication tasks as well?

 

[winnielinnie]

Here is a companion read, which compares and contrasts GELI (disk, partition) vs OpenZFS (dataset) encryption.

Among the new features arriving in OpenZFS on FreeBSD is a clever implementation of industry standard encryption at the dataset level. Effectively, this means that the FreeBSD storage encryption ecosystem previously dominated by GELI now has a new contender: OpenZFS “native encryption.”

(...)

GELI has been FreeBSD’s main native full disk encryption system for some time. (...snip...) However, GELI has absolutely nothing to do with ZFS. GELI encrypts an entire device, or at finer granularity, a partition on it. Thus, before first use of any filesystem protected in this way, the relevant devices or partitions have to be “unlocked.” Once unlocked, the underlying filesystem is recognized and mounted, typically for the duration of the uptime. Unlocking procedures are governed by a master key and up to two user keys that variously involve keyfiles and passphrases. This complex set of keys allows for the possibility of re-keying a GELI partition (e.g., in the case of compromise of one key) without having to re-encrypt data.

(...)

By mid-2019, ZFS-on-Linux (ZoL) 0.8 introduced native encryption support; that is, encryption of ZFS datasets themselves on supported Linux platforms. Thanks to the efforts of a number of people from ZoL and FreeBSD, this important capability will soon be realized for FreeBSD in version 13, expected around the summer of 2020. At the level of a filesystem encryption solution, we do not encrypt entire devices as in GELI. This is already immensely compelling; it is common to only desire encryption on a subset of sensitive data, and that data is probably naturally segregated into its own dataset as it is!

(...)

Furthermore, when sensitive data need not be accessed for a time, the dataset can be routinely unmounted where it subsequently becomes encrypted-at-rest, inaccessible to those without the key; this is not easily possible with GELI where typically an entire filesystem is decrypted at boot time and remains decrypted during the entire system uptime. Additionally, with GELI, the entire filesystem is protected by one set of keys, giving little granularity for access to different users; a user can either access the entire system, or none of it. With Native ZFS dataset encryption, different datasets can easily be given distinct keys. Those keys may then be provided to a given user in whatever access combination is appropriate.

(...)

At the same time ZFS native encryption is being introduced, ZFS send will now have the ability to send “raw” data blocks; that is to say, blocks are not interpreted in any way, and are sent as-is to the receiving system. In the case of natively encrypted datasets, this means that the key does not need to be loaded and data blocks can remain encrypted while in transit over the network, even when that transit (by accident or design) is itself not encrypted. This allows sensitive data to be backed up to a remote ZFS system without the remote system or its administrator (and, as has already been said, the local administrator) ever having access to the plaintext.

Come to think of it, would it be tricky for the TrueNAS developers to have both GELI and OpenZFS encryption methods live harmoniously in the same GUI without confusing the end-user? After all, "encryption" is a generic term used in the documentation and throughout the GUI menus and tooltips. If there are two encryption methods, they would have to be clearly differentiated and explained.

I have not tried out the 12 beta nightly, so perhaps someone else with experience can comment?

* Was in an IRC chat in regards to Linux Mint 20 Cinnamon Beta, which was released recently. Cross-wiring!

 

[danb35]

Am I correct to assume that beginning with TrueNAS 12 / OpenZFS 2.0, that I can simply create pools without any underlying GELI/encryption, and then later decide to encrypt specific datasets as needed?

This seems like a question that would be better placed in the TrueNAS forum than here, but yes, I believe this is correct. I've played with the 12 Nightly enough to say this, but not to answer your other questions.

I have not tried out the 12 beta

12 isn't close to beta yet.