secrets management

[Geal]

follow up on the discussion about jaeger username and password in #118

@cecton commented 15 days ago

@cecton was there a specific intention behind skipping the jaeger username and password during config deserialization? I think it should be allowed in the configuration file (even if we'd prefer the env variables, it's the user's call)

I think it was just for security reason because you can pass those via env variable

@Geal commented 15 days ago

the security benefits of environment variables are debatable (they tend to leak with monitoring tools that dump process environment on crash), so I'd rather let the user decide than mandate one way

@BrynCooke commented 15 days ago •

Environment variables to override secrets allow users to maintain their configuration in a ConfigMap while providing their secrets in a Secret. It's horrible when config and secrets have to be in one file as you end up having to put the entire thing in a sealed secret or similar.

I do think it's nice for local dev to have the secret directly in the config file though, so in favour of allowing both options with env variable taking precedence.

We should print the configuration at debug level whenever it is loaded, and in this case I would expect secrets to be redacted.

In my experience environment variables are not a good way to pass secrets either, since a lot of monitoring tools will bundle up the environment variables of a process when reporting errors or crashes.
Another way is integration with secret managers like Vault. Those need specific code in the router to support them, so we might want to avoid that too.

[cecton]

I think:

1. environment variables are not ideal but a valid option
2. having secrets in the configuration file is bad because it's a risk
3. having secrets in a separate secret file is probably the best and work better with k8s

So I think we should start having a file dedicated to secrets but still accepts env variables.

[BrynCooke]

+1 to the idea of having a separate file for secrets.
I take the point that there is a high chance of environment variables will be dumped to output, so let's remove this.

It should probably still be an option to specify the secrets directly in the config file, for development and in the case that users are using this: https://learn.hashicorp.com/tutorials/vault/kubernetes-sidecar.