Skip to content
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

Support seeding secrets from non-plaintext sources (consider using External Secrets Operator) #216

Open
justaugustus opened this issue Jun 22, 2024 · 2 comments

Comments

@justaugustus
Copy link

Highlighted by @mshoosht-cisco, there are several areas within the chart templates which may suggest the use/committing of plaintext credentials e.g.,

password: {{ .Values.server.basicAuth.password }}

It would be great to consider extending the chart to use External Secrets Operator, specifically ExternalSecret: https://external-secrets.io/latest/api/externalsecret/

Matt can say more, but I'm filing this to get the convo started!

cc: @lelia @sriaradhyula

@mshoosht-cisco
Copy link

A good initial start is to allow the secrets to be optional. This would support the chart being installed, but the secrets to be created by other means. ES Operator is one method, but manual, or CD could be another.

Here is an example that illustrates the use of a value in values file. The value can be defaulted to true to maintain current behavior(secret always created), but overridden to not create the secret if another tool is to be used. I have the complete solution. I can PR if there is interest.

{{ if .Values.dbmigrator.createSecret }}

In regard to the external secret controller, you could use a flag to use that. Supporting multiple secret generation processes may be cumbersome. Users of this chart could extend by calling this chart as a dependency and then having a template folder with the Helm external secret resources.

@tegioz
Copy link
Contributor

tegioz commented Jun 24, 2024

Hi! 👋

@justaugustus it's possible to use the chart as it is without using / committing plaintext credentials 😇 (i.e. using helm-secrets). Another option is to have the chart's custom values layered into multiple files, and store the credentials in one that'd remain encrypted until needed (i.e. to rotate keys).

But I understand that this may not work for some teams, so having some flexibility is great. Making the secrets optional -keeping the current default behavior- sounds good @mshoosht-cisco, and we'd gladly accept a PR for this 🙂 We'd like to keep it as simple as possible, so we'd rather not to include support for any specific secrets generation process at the moment. That can always be handled separately as you mentioned.

I will also update the CLOWarden server to allow configuration values to be set/overridden using environment variables in addition to be read from the config file (maybe it'll help eventually with further improvements to the chart).

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants