opportunistic encryption of state partition

[Ulexus]

The state partition should be encrypted, but it must be done without configuration, since the config is stored in the state partition itself.

Therefore, we propose a plan to use opportunistic automatic encryption in the following order:

1. If TPM is available, use TPM for key storage
2. Use a node-local, immutable piece of data (such as the UUID of the machine) to deterministically create a symmetric key. This is lower security, since it is a deterministic key, but it still better than nothing.
3. Failing either of the above, no encryption.

This allows us to use encryption if we can, while seamlessly falling back to the current method if it is not available.

Note that LUKS can handle detection of whether the partition is encrypted or not, and the presence of TPM determines whether the key can be recovered from there.

Possible tools:

• Luks.go
• gocryptfs
• age
• clevis/tang
• sharedsecret Shamir's Secret Sharing Algorithm

[smira]

We should also think about a case when bare metal machine gets reused for a different workload or tenant, and how can we protect from that, e.g. if we could use some kernel and boot loader checksum for the key seed, something close to secure boot. Just a thought for the future

[Ulexus]

Definitely. I'm leaning toward some form of secret sharing mechanism here, where part would be supplied by the hardware, and part from the environment.

[Ulexus]

It's a good point about the kernel + image hash as a seed. I threw that away because of upgrades, but in this case, we rewrite the config on upgrades. That would mandate keeping separate configs to match to each kernel+image combination, to facilitate rollbacks, but that is actually a good thing, too.

[Ulexus]

It's also an option to use something like age to simply encrypt the configuration file or something like gocryptfs to encrypt a directory, rather than the entire partition.

[dwa]

I like the idea of using clevis/tang, or have you ruled this one out?

[smira]

I like the idea of using clevis/tang, or have you ruled this one out?

no, nothing is ruled out. In fact, Talos implementation supports different methods for getting the actual encryption key. clevis/tang might be one of them, but it's not implemented yet.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.