Allow to load secrets from file

[fooker]

Allow to load secrets like database password or TMDB API keys from file.

• [x] I have checked the existing issues to avoid duplicates
• [x] I have redacted any info hashes and content metadata from any logs or screenshots attached to this issue

Is your feature request related to a problem? Please describe

Passing secrets using environment variables is discouraged and storing secrets in config files could be problematic when used in config management systems. Allowing to load secrets from files would allow secret management during deployment or use systemd credential services.

Describe the solution you'd like

Add additional configuration properties to load secrets from file.

Describe alternatives you've considered

Loading the secrets into environment variables in service pre-start.

Additional context

I'm building a nixos module for bitmagnet

[mgdigital]

I think systemd already allows for this? https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#EnvironmentFile=

[fooker]

I think systemd already allows for this? freedesktop.org/software/systemd/man/latest/systemd.exec.html#EnvironmentFile=

Yes, it does. But as stated right above the paragraph you've linked, this is discouraged as it is not suitable for secrets. All alternatives shown there require the secret to be loaded from a file by the application itself.

The best way to do this that I am aware of is to have some kind of syntax in the config file to load the value for a config option from a file.

[mgdigital]

But as stated right above the paragraph you've linked, this is discouraged as it is not suitable for secrets.

Okay, it seemed like the warning in the paragraph above was referring to that paragraph rather than the one I linked. From what I can ascertain using EnvironmentFile is more secure than Environment when locked down correctly but its use has been subject to some heated debate (sources https://nickb.dev/blog/writing-a-secure-systemd-service-with-sandboxing-and-dynamic-users/ and https://systemd-devel.freedesktop.narkive.com/ibRtoqPS/environment-variable-security).

The only current secrets are the Postgres password (which need not be specified if socket access is used), leaving only the TMDB API key, so although the attack surface here is already minimal I'm happy to get this locked down when other priorities permit, especially as further secrets may be added in future. The simplest solution is probably to add something like config.extra.yml to the files that the config resolver looks for (https://bitmagnet.io/setup/configuration.html#configuration-precedence), allowing secrets and other config to be separated. I'd favour this for simplicity over developing a syntax for loading individual secrets from files.