mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #4353] [Feature Request] dedicated secrets file #3438
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#3438
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @crabdancing on GitHub (Jul 27, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4353
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 sayauth.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
@fatedier commented on GitHub (Jul 29, 2024):
I think it's feasible. Are there any widely used projects that have adopted this approach that we can learn from?
@crabdancing commented on GitHub (Jul 29, 2024):
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 aURI, 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
*_FILEenvironment 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
legoby 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.