[pve-devel] ZFS encryption

[Fabian Grünbichler]

On Wed, Apr 04, 2018 at 03:47:57PM +0200, Andreas Steinel wrote:
> Hi Fabian,
> 
> On Wed, Apr 4, 2018 at 9:45 AM, Fabian Grünbichler
> <f.gruenbichler at proxmox.com> wrote:
> > On Tue, Apr 03, 2018 at 08:45:59PM +0200, Andreas Steinel wrote:
> >> Hi everyone,
> >>
> >> are you (Proxmox staff) actively testing encrypted ZFS or are you
> >> waiting for the upstream "activation"?
> >
> > if you are talking about upstream's native encryption, then AFAIK none
> > of us are testing that (yet). it's not part of any ZoL release (only the
> > development branch), and it has shown in the past few months that not
> > including it in 0.7 was the right choice for sure (1 issue requiring a
> > backwards incompatible on-disk format change, several that completely
> > broke send/recv in certain scenarios).
> 
> I just learned that it was part of 0.7.0 and the ArchWiki explains its usage:
> https://wiki.archlinux.org/index.php/ZFS#Native_encryption

that's a frequent source of confusion, since ZoL from the master branch
does not have a 0.8 version. when you see a version like 0.7.0.r26 or
containing a git commit ID, it's likely a build of some version from the
master branch. when you see a version like 0.7.x where x > 0, it's a
stable release from the 0.7 series.

> I did not find any flag to enable it in the current source, so you're
> right. It's
> there in GIT, yet not merged with the release itself. That was my impression
> before reading in the Wiki as well.
> 
> > it will most likely be part of 0.8, and if that gets cut in time for PVE
> > 6 we will surely take a closer look again when we start preparing for
> > that.
> 
> Looking forward to it. Hopefully, other features from illumos will also be
> part of 0.8 like vdev shrinkage etc.

basically everything that is in master is slated for the next release,
unless major problems show up and something needs to be reverted.

> 
> > do you have specific use cases in mind?
> 
> You mean besides fulfilling GDPR?

I meant more from a technical point of view ;) the reasons for wanting
to encrypt stuff are rather obvious, although there are a lot.

> 
> > Grub does not currently support the ZoL encryption, and I am not sure if
> > and when it will get support. that means it would probably not work out
> > of the box for the root dataset (unless we switch to a completely
> > different boot approach, which does not seem very likely at the moment).
> > it is per dataset though, so encrypting the guest datasets should be
> > possible without much hassle.
> 
> Yes, that'll going to be hard. LUKS is better at this with preboot
> authentication and stuff like that.

Grub can even decrypt LUKS on its own, so you can have just the
stage1(.5) unencrypted :)

> 
> > (I do use ZoL on top of LUKS as / on a few systems without any problems,
> > but it requires manually bootstrapping the system and a bit of fiddling
> > to get all the parts to play nice with eachother ;))
> 
> Yes, I'm using ZFS on top of LUKS already, yet an "internal" solution could
> be better. The workflow as described in the ArchLinux Wiki is not that easy
> in practise as someone would want. It is basically the same as LUKS,
> which is proven to work marvelously.

I am sure the integration of the key loading will be improved further
the closer the 0.8 release gets - right now the native encryption is
still very much in a "see which stuff fails" kind of state, although
there are already quite a few people over in #zfsonlinux that use it
quite heavily.