Allow Encryption of ix-apps

Feature Requests
1

Problem/Justification
Based off what I have read ix-apps stores docker containers (apps) on it. Right now this dataset is not allowed to be encrypted. This is an issue as this would reveal a lot of data, including what docker containers are installed but more then that it would reveal all internal data of that container if I understand correctly. While you can use host-paths to mount some data to an encrypted dataset. Some applications store sensitive data within the container. Additionally, you may want to pass some sensitive data into a container as an environment variable. Environment variables are also stored unencrypted in ix-apps.

A user could also use ix-volumes to store stuff that the docker app requires mounts for, which would then be stored unencrypted in ix-apps, but that is less of a concern as you can use host-paths instead.

I understand that Self-Encrypting drives exist and can be used however, this should be available for everyone, including people who do not use self-encrypting drives.

Impact
This is a security issue, when I enable encryption for pool and inherit it to datasets I expect all data to be encrypted. Not for a special rule to override this for ix apps. I understand there was some issues with data migration and other things, which is why this feature was disabled. However, I think making this an option and warning of those issues would be good enough.

Implementing this feature would enhance security, and if implemented behind an option with a warning would not have drawbacks the user was not warned of.

Additionally, data contained within docker containers is not intended to be persisted forever. As when a docker container is deleted, updated, or recreated that data is lost. However this data is still stored on the disk, which persists through system restarts, and can contain sensitive information, which is why it should be allowed to be encrypted.

However, I am wondering if only allowing migration though an automated process of deleting the ix-apps dataset and the creating a new one in the new location would solve the issues that caused this feature to be removed in the first place. This would break ix-volumes though.

User Story
When creating a dataset for ix-apps the user is asked if they want to allow encryption on the dataset. If check the box is checked a warning in a yellow box is displayed. This warning warns of potentially issues the user may encounter.

For more info see this ticket where the feature was also requested.

https://ixsystems.atlassian.net/browse/NAS-123318

This thread is also relevant SOLVED - How to best resolve this warning? "datasets are not encrypted but are within an encrypted dataset" [22.12.3] | TrueNAS Community

1 Like
2

If the pool’s root dataset is encrypted, the “ix-apps” dataset (which is nested under the root dataset) is still created as unencrypted?

Please tell me that’s not still the case…

That violates TrueNAS’s own restriction: “Thou shalt not create an unencrypted dataset underneath an encrypted one.”

I’m not joking. If you try to do it yourself, you will be stopped and met with a red warning that tells you it’s not allowed.

But they do this anyways for the new “ix-apps” dataset? I thought this wouldn’t be the case any longer, after they switched from K3s to Docker.

3

According to the docs sadly that is the case.

The ix-apps dataset does not inherit encryption if an encrypted pool is selected as the pool for applications.

4

If it makes you feel any better, we cannot encrypt the syslogs anymore, which is still possible with Core.[1]

  1. With an encrypted root dataset, and the syslogs set to store in the System Dataset, everything remains inside an encrypted space. ↩︎

5

I’d vote for this, but I am currently all tapped out.

Me, I have all of my Docker apps’ data on a passphrase encrypted dataset and I wrote a bash script that, on boot, unlocks the dataset and then proceeds to start my containers one-by-one. It works well enough, but it’s such a nuisance to have to do that in the first place. TrueNAS is all about security and encryption…except when it actually matters!

6

Same.

7

Another feature request I guess. I am concerned that security seems to be getting worse compared older versions of TrueNas.

1 Like
8

Amusing… :grin:

1 Like
9

TrueNAS started with rock-solid software & data-protection, but then they started with too many experiments in the past few years, which lead us to bad documentation, many app-migrations and decreasing data-protection. The only good parts still existing in TrueNAS is ZFS, and a nice webui for snapshots and data-replication. Maybe we have to think about alternatives…

1 Like
10

At least for my needs, there are not alternatives better than TrueNAS

11

Which changes have decreased data protection?
As for the various app systems, if you’re using TrueNAS purely for storage, you’re not affected.

12

Apps

13

For now I’m using a VM with Docker-Apps on an ecrypted storage. Very large overhead to achieve encrypted Apps.

14

I’m not sure if this actually works as a workaround, because doesn’t the system docker install only store metadata to the unencrypted dataset even if you use the command line manually? It looks to me like the command isn’t even available until the apps pool is online.

15

For now I’ve just turned on encryption of the ix-apps dataset manually, which was the setup I had back on (Bluefin?) as well. It’s not a production system, so if it breaks stuff that’s fine, but working without issues so far!

16

I’m not using the TrueNAS docker install, I am using custom YAML and as such I can define the volumes wherever I want, namely in the encrypted dataset of mine. Then it’s just a matter of copying the YAML in there as well.

I’m not saying it’s a good workaround, but it works until (and if) they ever implement proper support for encrypted Docker datasets.

17

Might this thread be changed to also include Incus VMs and containers? It is a major issue for me that I can’t encrypt those, but it’d be a tad redundant to make a separate thread just for Incus VMs and containers when the basic issue is the same.

Not being able to encrypt VMs and containers (in my case using passphrase, not passkeys!) makes TrueNAS as a host for those practically useless for my needs. At least with the old KVM VMs I could use encrypted datasets.

1 Like
18

Wow really, I thought you would be able to create a password encrypted zvol.

Also, I don’t think I can update the title or the OP any more.

Its unfortunate that truenas keeps going backwards with security. I also learned that when changing from a key to a password based encryption the actual key used to unlock the dataset is not securely deleted so for an unspecified period of time the even if you change to password encryption the key is still left on the disk. This one is more on OpenZFS but TrueNas can and should mitigate it.

You can read more about that issue in the OpenZFS docs under change key.

https://openzfs.github.io/openzfs-docs/man/master/8/zfs-change-key.8.html

The best solution there is to allow creating everything with a password based encryption upfront.

19

I finally got around to trying to create VM from existing KVM ZVOLs and it did not go well. Apparently, in TrueNAS parlance, cloning a ZVOL doesn’t actually mean a real clone: if your original ZOL is encrypted and you decide to clone it into Incus’s stupid volumes thing, TrueNAS will change the encryption root of your original ZVOL to that clone – I would expect a clone to be literally that, a clone that doesn’t affect the original ZVOL in any way or form.

Just one more way encryption is completely broken in TrueNAS with Incus. At this point, I hate the whole thing and how they’ve gone about implementing it.

20

Help me understand something. This also affects LXC containers?

I thought using “Linux jails” in SCALE would allow them to reside in encrypted datasets, in the same way that was allowed with iocage on Core?