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.
I don’t see the need to encrypt the app itself, I just encrypt the part that matters which is the application data.
Maybe that’s because you have a different threat model. Anyone with physical access to the system can tamper with unencrypted partitions/drives. While this may or may not be a concern for iX’s enterprise customers (it should be; I did cybersecurity for 35 years) my current understanding of how apps (meaning Docker) on TrueNAS Scale work means that trusted images can be replaced with modified images and you’d never know.
Even if your data is on an encrypted partition—not guaranteed as the iX apps databases and such are also set up on unencrypted partitions&mdashyou have a vulnerability in the app itself. There’s no secure validation step that you’re running the container you think you’re running, and that’s a massive security hole.
Honestly, absent a published threat model from iX, I’m not sure what their threat model is. I just know that as a cybersecurity person and and former CISO I’d kick TrueNAS to the curb for sensitive or regulated data. YMMV.
The threat model is where this goes sideways, because two different properties are getting collapsed into one.
Encryption is a confidentiality control. It answers one question: if someone gets the bits while the system is off, can they read them. “Am I running the image I think I am” is an integrity question, and encryption doesn’t touch it. Encrypt the entire ix-apps dataset and you’re exactly as exposed to image substitution as before, because a swapped image is still a valid, readable image. The control for that is signing and verification (Docker Content Trust, cosign), not encryption.
The two halves also don’t connect. Replacing a trusted image takes write access to the host, and anyone with that operates at runtime, when the pool is unlocked and keys are in RAM. Encryption at rest buys nothing there. What it does defend is the drive that walks out the door, the RMA, the decommissioned disk, which is exactly why encrypting the application data is the right call.
You’re right that ix-apps isn’t encrypted by default (open feature request) and that Docker doesn’t verify signatures out of the box. Those are fair asks. But they’re config and ecosystem gaps with their own specific fixes, not a massive hole you close by encrypting the apps. Each threat has a control that matches it. Pile them all under “encrypt everything” and you’ve muddled the model, which is the opposite of what a threat model is for.
Also worth noting that in the context of business / enterprise use they don’t run apps on the NAS, it is just a storage device.
Not to get in the way of the conversation here, but as a general statement, we do offer support for SED drives which are commonly used by our Enterprise customers to solve these sorts of problems. When possible, it’s typically better to do in hardware as opposed to software.
Encryption is a confidentiality control. It answers one question: if someone gets the bits while the system is off, can they read them. “Am I running the image I think I am” is an integrity question, and encryption doesn’t touch it.
I do this for a living, so I’ll be intellectually honest and start by acknowledging that you are technically correct in your distinctions. However, from a more pragmatic point of view most useful encryption systems include signature algorithms or hashing algorithms to ensure non-repudiation or to provide tamper-resistance.
For tamper-proofing .ix-apps and similar from an app image perspective, Blake3 or AES-256 (which is often hardware-accelerated on most modern CPUs) would be fast and reliable for verification without depending on encryption, but since .ix-apps also holds credentials, databases, logs, and who knows what else I think that real encryption with hashing is essential for any reasonable threat model for home or office.
Debian-based systems can run debsums on installed packages, and even a thumb drive with xxHash-3 or xxHash64 would be better than the non-security we have today. The tools are easily available for the modified distro underneath TrueNAS, and I could submit a patch…if. The problem (as usual) is that I don’t really understand the middleware and without middleware support the whole thing is a non-starter. I already make a lot of security changes in the middleware-supported boot scripts, but it’s like sewing with mittens on.
As a CISO, I would never allow TrueNAS in my data center without changes to its default security posture. That’s just me, though, and clearly iX systems has paying enterprise customers so maybe I’m in the minority. I’d be curious to know how many sales they lose due to various insecure defaults that patching renders unsupportable, though. It is unlikely to be zero, and that’s unfortunate since I like TrueNAS.
Covers self-encrypting drives including supported specifications, implementing and managing SEDs in TrueNAS, and managing SED passwords and data.
This was true in 25.04, but 25.10 removed whatever support the middleware had for my drives and enclosures. 25.04 was successfully using global SED, but several weeks of tinkering failed to provide the necessary functionality if OPAL isn’t detected.
SED is also mostly a control for “walking out of the data center with a drive in your hands.” It’s not really the same as boot-time encryption of the keystore, random encryption of swap zvols–and nuts to anyone who thinks this is unreliable or not useful; Linux always performs better with some swap and especially properly-configure zswap–or whole-disk encryption with LUKS.
Secure remote boots using a KVM-over-IP allow you to use passphrases instead of on-disk keys, but since the boot volume is unencrypted you have no tamper-resistance or encryption there, either (see my other comments about that). This is a ridiculous security posture to take, as a compromised boot disk compromises the whole system no matter what else you do.
If anyone has gotten global SED to work in 25.10+ with non-OPAL drives, let me know. Otherwise, this is not a Linux problem but a middleware problem that I don’t know how to work around even with CLI access to sedutil-cli.
