-
Notifications
You must be signed in to change notification settings - Fork 36
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
Better secrets control #35
Comments
@zs-ko apologies but could you give more examples, I'm a better backend engineer than devops and just want to make sure I understand the issue and proposed solution :) |
Sure. So when loading secrets from something like vault it is mostly rended as a simple key value. We can then either mount these files directly to the container on a path or rended it trough a template language (Not supported by all secret secret providers/vaults)
By allowing the secret to be defined in that manner you will need to start windmill with a script to inject the secret or add flags to windmill to support this kind of configuration.
This could also be used for other parameters as well. OAUTH_SECRET_FILE and so on. Example env from the database pod in namespace windmill exposing windmill pods env
|
Currently the helm is reading secrets trough environment variables. This limits the way we can inject secrets into the deployment.
Add support for reading secrets from files.
Add Env variables that point to files instead of directly to the secret value
DATABASE_URL_FILE="/some/container/path/file"
This will also adapt to different secret management methods. Like when using Hashicorp vault and dynamic database credentials
The text was updated successfully, but these errors were encountered: