You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a system administrator i want to check my headscale-config into a git repository. Having secrets in git is considered bad practice, so any headscale-configuration with postgres.pass set, should not be pushed into a git-repo.
Description
If you want to have your configuration versioned, at the moment you are left with the options "using postgres via socket" or "using sqlite" since the password to your database-server would also be checked in.
Being able to read the postgres-password from a file in the headscale-config let's us treat the configuration as "non-secret".
In Docker this file could be bind-mounted by the admin , in a kubernetes-enviromnent it could be set as a secret; which both would no longer be headscale's concern.
Contribution
I can write the design doc for this feature
I can contribute this feature
How can it be implemented?
In my opinion, treating the postgres-password the same as the oidc-client-secret would be perfect:
Equivalent to oidc.client_secret_path i could imagine an option like postgres.pass_path to read the password from a file.
The text was updated successfully, but these errors were encountered:
Use case
As a system administrator i want to check my headscale-config into a git repository. Having secrets in git is considered bad practice, so any headscale-configuration with
postgres.pass
set, should not be pushed into a git-repo.Description
If you want to have your configuration versioned, at the moment you are left with the options "using postgres via socket" or "using sqlite" since the password to your database-server would also be checked in.
Being able to read the postgres-password from a file in the headscale-config let's us treat the configuration as "non-secret".
In Docker this file could be bind-mounted by the admin , in a kubernetes-enviromnent it could be set as a secret; which both would no longer be headscale's concern.
Contribution
How can it be implemented?
In my opinion, treating the postgres-password the same as the oidc-client-secret would be perfect:
Equivalent to
oidc.client_secret_path
i could imagine an option likepostgres.pass_path
to read the password from a file.The text was updated successfully, but these errors were encountered: