The install guides through 25.10 say not to encrypt the root dataset. The hidden .ix-apps and such ignore it anyway if you encrypt the root. However, I can’t find any documentation regarding how to move either apps or containers to an encrypted dataset.
Basically, any time I try to configure an app or container with data or configuration on an encrypted dataset, it usually fails to install due to permissions issues but what the permissions ought to be aren’t clear. What’s so special about the .ix-apps permissions that it allows most apps to install cleanly? Can that be replicated on an encrypted data set?
In addition, does TrueNAS check whether a container is untampered with before running it? Containers have hashes, but since ZFS supports Blake3 and other cryptographic hashes there’s an opportunity to add a level of HIDS to images stored on unencrypted (and thus vulnerable to unauthorized modification) datasets.
I’m bothered by the inability to encrypt the boot and root datasets, but not allowing the default (or even manually easy) encryption or validation of apps and containers baffles me. Security is always a trade-off, but the upside here escapes me other than “at least most apps/containers don’t break most of the time.”
There should be a middle ground, but I haven’t found it in the documentation. What have I overlooked?
I don’t see the need to encrypt the app itself, I just encrypt the part that matters which is the application data. The permissions are no different, you create a dataset with encryption either key or passphrase. Then you set the permissions of that dataset to the proper permissions (usually app) then you set up the data fon an app to use that dataset.
WARNING, the below is unsupported, keep a fire extinguisher on standby.
It is possible to send/receive with the -x encryption property to receive into an encrypted parent w/ inherited encryption. then rename it into place with the docker service stopped. (don’t use passphrase as since it’s hidden from the webui it can’t be unlocked and being inaccessible at boot would cause the docker service to fail to start).
afaik this causes no problems with the exception of newly created ix-volume datasets are still created unencrypted (my main system has been running like this for some time, I did this with the understanding that I can self-support if I need to though, I also ran with a similarly encrypted ix-applications k3s dataset too, with no real issues).
the forced unencrypted is mainly due to legacy reasons ie the migration from k3s to docker where the datasets were forced unencrypted to avoid “edge cases”. however most edge cases with ZFS native encryption are due to the fact that you can’t encrypt/decrypt an existing dataset and importantly for ix, you also can’t encrypt/decrypt clones of existing datasets which are how they handle migrations.
Also vote on this feature request so we can have it officially, it’s silly this is still a limitation.
