The encryption property for the children is inherited by default from the parent dataset, so we can see the following: zfs create -o encryption=on -o keylocation=prompt -o keyformat=passphrase banshee/encrypted Let's say we create an encrypted dataset named pool/encrypted, and beneath it we create several more child datasets. The contents of encrypted datasets or zvols are protected from at-rest spying-but the metadata describing the datasets/zvols themselves is not. OpenZFS native encryption isn't a full-disk encryption scheme-it's enabled or disabled on a per-dataset/per-zvol basis, and it cannot be turned on for entire pools as a whole.
OPENZFS SCRUB ALL POOLS FULL
This works for either full replication (moving every single block across the wire) or asynchronous incremental replication (beginning from a commonly held snapshot and only moving the blocks that have changed since that snapshot). In the event that you need to recover your offsite backup, you can simply replicate it back to your own location-then, and only then, loading the decryption key to actually access the data. This means you can replicate your offsite backups to a friend's house or at a commercial service like or zfs.rent without compromising your privacy, even if the service (or friend) is itself compromised. With raw send, your data is replicated without ever being decrypted-and without the backup target ever being able to decrypt it at all. This means that you can use ZFS replication to back up your data to an untrusted location, without concerns about your private data being read. Advertisementįurther Reading : ZFS Replication to the cloud is finally here-and it’s fastThere's an even more compelling reason to choose OpenZFS native encryption, though-something called "raw send." ZFS replication is ridiculously fast and efficient-frequently several orders of magnitude faster than filesystem-neutral tools like rsync-and raw send makes it possible not only to replicate encrypted datasets and zvols, but to do so without exposing the key to the remote system.
This can be a noticeable challenge for ZFS systems with many disks-in some cases, many tens of disks. Another problem with encryption-beneath-ZFS is that the extra layer is an extra thing to go wrong-and it's in a position to undo all of ZFS' normal integrity guarantees. One of the gnarliest is that each individual disk that will be part of the pool must be encrypted, with each volume loaded and decrypted prior to the ZFS pool import stage. In fact, the attacker can't necessarily see that ZFS is in use at all!īut there are significant disadvantages to putting LUKS (or similar) beneath OpenZFS. Putting something like Linux's LUKS underneath OpenZFS has an advantage-with the entire disk encrypted, an enterprising attacker can no longer see the names, sizes, or properties of ZFS datasets and zvols without access to the key. As mentioned in the introduction, LUKS, VeraCrypt, and many other schemes are available and can be layered either beneath or atop OpenZFS itself. There's more to OpenZFS native encryption than the algorithms used, though-so we'll try to give you a brief but solid grounding in the sysadmin's-eye perspective on the "why" and "what" as well as the simple "how." Why (or why not) OpenZFS native encryption?Ī clever sysadmin who wants to provide at-rest encryption doesn't actually need OpenZFS native encryption, obviously. OpenZFS' encryption algorithm defaults to either aes-256-ccm (prior to 0.8.4) or aes-256-gcm (>= 0.8.4) when encryption=on is set.
This obviates the need for separate tools like LUKS, VeraCrypt, or BitLocker. First introduced in OpenZFS 0.8, native encryption allows a system administrator to transparently encrypt data at rest within ZFS itself.
One of the many features OpenZFS brings to the table is ZFS native encryption.
0 kommentar(er)
