Even if their key is available, you must import them first before the zfs dataset is mounted and ready to use (it looks like an rc.d service was written and reviewed to facilitate doing this on boot, which I’ll need to investigate). I had initially assumed that using keys would result in the zfs datasets automounting when the zpool is imported, which is not the case. Wait, hold on, that’s it? Yes! How cool is that!? Gotchas => pool/tank keylocation file:///root/example.key local # zfs get encryption,keylocation,keyformat pool/tank o keylocation=file:///root/example.key pool/tank You can also verify the operation and check the encryption scheme used with zfs-get(8): # zfs create -o encryption=on -o keyformat=hex \ After that, we create a zpool(8), which has the encryption feature available by default on FreeBSD 13: # zpool create pool "/dev/gpt/$_LABEL" You can prepare your drive with gpart(8) and create a key as per above. What’s even cooler is that all of ZFS’s data integrity, deduping, compression, exports, and other features can operate on these encrypted datasets, even if they’re not imported/mounted. OpenZFS’s native encryption operates at the dataset level, negating the need for a GELI device that has to be mounted separately. OpenZFS inline encryptionīy contrast, is a phrase with two words. This may still be preferable in some circumstances, as we’ll get to in a moment. GELI is device and file-system agnostic, and ZFS is unaware (AFAIK) that it’s operating within a virtual encrypted device. The key here is you’re encrypting the entire partition beneath ZFS. When you restart, you perform the geli attach then zpool import as normal. This uses a plain disk, but you could just as easily build this on top of an iSCSI mount, or a HAST volume. # geli attach -pk "$_KEY" "/dev/gpt/$_LABEL" # geli init -P -K "$_KEY" "/dev/gpt/$_LABEL" # gpart add -t freebsd-zfs -l "$_LABEL" /dev/ada5 Note in the final step we reference the virtual encrypted device: # _LABEL="12TB-IronWolf-SERIALNO"
We create a new GPT layout, label it (you’ll be glad you did), create a key, create a new virtual GELI encrypted block device, then build our ZFS pool on top. Here’s an example of a typical encrypted ZFS volume using GELI. It’s proven, well tested, and secure, like my hat. GELI was the most recent and accepted tool to achieve this, akin to cgd on NetBSD, or LUKS on Linux. We’ve always been able to encrypt ZFS on FreeBSD, albeit with an intermediate layer performing the encryption before our data hits the disk. It still works, and will for the foreseeable future.Ī shiny new set of drives for my home server finally gave me the kick up the proverbial posterior to give it a shot with some prod data that definitely isn’t a Plex server for anime. I also didn’t feel as compelled to rush out and replace my GELI encrypted volumes as I first thought. I’d used the closed-source equivalent on the last Solaris, and had made some proof of concepts on the -CURRENT branch, but I hadn’t used it for any real world data. I’ve mentioned many times how excited I was for OpenZFS in FreeBSD 13, due in no small part to its inline encryption capabilities.
As opposed to a professioion? WHOA, is that how that works? Don’t answer that.