Services that can't pull secrets from files referenced in their configuration are my bane. Especially those that don't use environment variables either.
I don't want to put credentials in a config file which I plan to version control. I'd prefer not to put secrets in environment variables either, but I can compromise on that.
But when the service does not support either that makes me very sad.
=> More informations about this toot | More toots from algernon@trunk.mad-scientist.club
In this current case I've been banging my head against, I'm doing some funky #systemd & #NixOS magic.
The idea is that the NixOS module for this particular app will have a config and a secret-files option set for the services.$program attribute. The latter is something to fill with sops-nix file paths and stuff.
At build time, I will replace any values in secret-files with #path.to.key (eg, secret-files.something.token = "blah" will become secret-files.something.token = "#something.token#).
Then, the systemd service fille will have an ExecStartPre=, which calls a script that replaces all the #blah# tokens in the config file template, and shoves it in $RUNTIME_DIR/etc/config.toml, and the program will use that.
This way the secrets aren't in the store, aren't in environment variables, and the config file only lives as long as the service is running, and is pretty much bound to it in every possible way.
I wouldn't have to do this, if said app would be able to load secrets from files itself, but alas... I could just encrypt the entire configuration file, but that's going to be a big fat nope.
Working with encrypted files is a pain in the ass, and I want most of my configuration in the clear, and documented - not something I can reasonably do when the entire config file is encrypted. Not in a way I want to, anyway (embedded comments are not documentation).
=> More informations about this toot | More toots from algernon@trunk.mad-scientist.club
Cursed.
Could be improved further, to use DynamicUser=true. I'd just need to LoadCredentials the secret files first. But that's a task for another day.
=> More informations about this toot | More toots from algernon@trunk.mad-scientist.club
@algernon The way I handle this is with a combination of git-crypt and pass.
You can use git-crypt to have a secrets.nix file encrypted in your repo, and keep it decrypted localy, or have a script decrypt before nix-rebuild.
Then I use pass store for anything more secret and there is usually a way to get programs to read from the pass store as needed, or you can write a wrapper around your app launcher that will get the secrets from the store at runtime.
=> More informations about this toot | More toots from yisraeldov@linuxrocks.online
@yisraeldov
So the wrapper is exactly what I'm writing. But it sucks.
=> More informations about this toot | More toots from algernon@trunk.mad-scientist.club
@algernon Why not just encrypt one file of secrets and import it?
=> More informations about this toot | More toots from yisraeldov@linuxrocks.online
@yisraeldov I do that, kind of. Still need to inject the secrets into a place the application actually understands. As I said, storing secrets is not the problem. Making them available to the program is.
Not unsolvable, but... not pretty. (Example usage here)
=> More informations about this toot | More toots from algernon@trunk.mad-scientist.club This content has been proxied by September (ba2dc).Proxy Information
text/gemini