Comment by lelanthran

> Whenever someone says "But it should have been encrypted!" about things like configs on a server, I ask them how they'd implement that in practice.

Short practical answer: Use a USB HSM plugged into your server and acknowledge that it is an imperfect solution.

For configs, I used to setuid the executable so that it starts up as a user that can read the file, it reads the file into RAM in the first 5 lines in `main` then drops privs immediately to a user that can't read the file, and then continues as normal.

This was to ensure that if the application was compromised, the config could not be changed by the application itself, nor could it be read once the program was running.

If you wanted to keep it encrypted without leaking the key, you could do the same, except that the key would also be read at startup (or, preferably, get a data key from the USB HSM, and use that for decryption).

Of course, that moves the problem of "read the first key from disk" to "read the HSM pin from disk".

You can have your supervising program, like a K8 cluster, inject the correct keys into the pod as it's created, but that cluster itself needs a root key to decrypt those correct keys, and that has to come from somewhere too.

There is, at the end of the day, only one perfect solution: when the program starts up it waits for user input - either the decryption key or the HSM pin - that it uses as a root key to decrypt everything else.

There is no other way that isn't "store some root key, credential, token, etc on the computer".