-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load sensitive config values from "secrets" #7
Labels
Comments
Hi @seoester, I like the idea! |
moqmar
added a commit
to moqmar/diun
that referenced
this issue
Oct 12, 2019
This can probably be improved a lot (e.g. what to do with undefined environment variables, how to treat escaping of variables, adding conditional clauses, and so on), but by then it would probably be wise to just use a prebuilt config parser with environment support.
moqmar
added a commit
to moqmar/diun
that referenced
this issue
Oct 12, 2019
crazy-max
changed the title
Feature Request: Load sensitive config values from "secrets"
Load sensitive config values from "secrets"
Nov 19, 2019
crazy-max
added a commit
that referenced
this issue
Dec 14, 2019
Merged
@Leopere Done through release 2.0.0. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some fields of the configuration contain sensitive values:
notif: mail: password
regopts: <name>: password
notif: mail: username
regopts: <name>: username
Loading these values from a "secrets" mechanisms would be advantageous when deploying diun through an orchestration platform such as Kubernetes or Docker Swarm.
This could be achieved by reading the value from a file or an env var. Reading from an env var is a more universal pattern (12 factor app) whereas reading from a file would support the "secrets" mechanisms of both Kubernetes and Docker Swarm (and is arguably more secure).
The simplest solution I can think of is introducing additional configuration fields, e.g.
notif: mail: password_file
.password_file
contains the path to a file from which the password is read, while perhaps truncating trailing whitespace.password
would take precedence overpassword_file
.I could also see some benefit from providing
username
as a secret, as it is part of the credentials.notif: mail: credentials_file
could be an alternative, where the file specified is a yaml document containing theusername
andpassword
fields.Thanks for considering this and keep up this great project :)
The text was updated successfully, but these errors were encountered: