fatedier
[Feature Request] dedicated secrets file
Describe the feature request
Rather than only having the option for auth.token = <value> (e.g. auth.token = "thisismysecret") in the config, it would be ideal to have the option to say auth.token_file = <path>. (e.g., auth.token_file = /var/lib/secrets/frp_token.) The token secrets can then be loaded from those files by frp during initialization.
Putting a secrets file in a dedicated location is a useful standard for segregating secrets in their own directory, thus reducing the likelihood of mistakes when configuring file system permissions & file scope. It also reduces the likelihood of leaks if, e.g., someone is committing their configuration into version control / git (such as is de facto necessary in some workflows, such as NixOS).
Describe alternatives you've considered
No response
Affected area
- [ ] Docs
- [ ] Installation
- [ ] Performance and Scalability
- [X] Security
- [ ] User Experience
- [ ] Test and Release
- [ ] Developer Infrastructure
- [ ] Client Plugin
- [ ] Server Plugin
- [ ] Extensions
- [ ] Others
I think it's feasible. Are there any widely used projects that have adopted this approach that we can learn from?
Absolutely!
People recommend configuring secret_file in GitLab.
Gitea/Forgeo also have a similar feature. You might perfer that one since it's written in the same language as frp. They use a URI, with a file being a specific URI protocol. Kinda weird, but it works, and has some interesting implications.
Another example that I have personal familiarity with is Authelia, which uses environment variables for configuring secrets and has *_FILE environment variables to load the secrets from a file instead of the environment variable directly.
I think that lego also uses an approach like that, although I'm not completely clear on the details there. (I maintain it with a Nix expression, so I can't remember ever configuring lego by hand.)
The environment variable approach seems entirely servicable, and it really doesn't make much difference from the perspective of automated configuration tools like NixOS, but I think having a direct configuration option like the former examples requires less thought on the part of the user. As opposed to environment variables, which might require e.g. knowing how to modify an environment variable in a systemd unit using a fragment file, or overriding the entire service shipped by a user's distro, etc.