Hey, is there a way to do full disk encryption, or at the very least make the contents of each zone encrypted? I tried in the past, but struggled with it unlocking at boot before anything else could run. I know that VMs can be encrypted via their installed OS's (at the expense of being a pain to restart), but that doesn't account for the OS containers I think.

Charadon on paper, there is zfs encryption.

tsoome: Insanely late reponse, sorry, but I have looked into ZFS encryption, the issue is that I have no idea how to make it unlock the partitions at boot before it tries to start any VM, which of course leads to some errors. I had the idea to use a usb key to store the encryption keys, so maybe I'll try that

I also had an idea to make an SMF service that holds up the boot process until the passphrase is entered, but I have no idea how to go about doing that.

I'd rather do the passphrase, as my mind is a better safe than, well, an actual safe for the usb key, cheaper too lol

Charadon: It's intended to use a hardware token (like a yubikey)

bahamat: Since it's a home server, I feel a yubikey is a bit over-kill and expensive. Honestly, if I could just get it to run zfs load-key -a at boot, it would basically solve all my problems

Well, the feature in SmartOS was designed for Triton.

Having a key that can anywhere that would be useful at boot time completely negates all benefits of encryption.

well, depends

Compared to having a yubikey that will always be in the same room as the server?

If this was a datacenter, i'd agree that it's way better than a passphrase. But in this instance, if I used a usb key or yubikey, it will always be in the same area as the server since it's a home server

So a burgalar (The threat model i'm trying to protect against) could just yoink both

Right, so what good does it do you?

Yeah, that's why I want a passphrase preferably, as in the end, they'll either have to spend an eternity cracking it, or (more realistically) give up, and just wipe the drive. Thus my data is safe

The thing is, you really need it unlocked before filesystem/smartdc starts up, because that's what mounts the pool. But you can't get anything custom until after /opt is mounted, which happens as part of filesystem/smartdc.

You're better off using delegated datasets and just encrypting the dataset inside the zone.

Basically, pre-create a dataset with encryption before making an instance?

No, create an instance with a delegated dataset. Inside the instance create a child dataset with canmount=off,encryption=on

Then you can zfs mount it interactively.