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 existing secrets/config mapping #23

Open
bufke opened this issue Feb 13, 2023 · 1 comment
Open

Support existing secrets/config mapping #23

bufke opened this issue Feb 13, 2023 · 1 comment
Assignees

Comments

@bufke
Copy link
Contributor

bufke commented Feb 13, 2023

Use case: I'd like to store a non-helm managed secret or configmap and map it to kpi env vars. This is nice for shared credentials, such as sharing AWS keys between multiple staging servers

@bufke
Copy link
Contributor Author

bufke commented Mar 24, 2023

This might be a good task @LMNTL but consider it low priority. We should follow bitnami standards for this. See the "existingSecret" value for example. The use case is this:

I have 0-to-infinite staging servers in a particular namespace. Perhaps they are feature branch review instances. Right now, I need to maintain a lot of yaml files to set each one up. I could reduce a lot of this copied configuration if I instead referenced a shared secret or config map. Maybe all my staging servers use the same AWS credentials for django-storages. Instead of copying yaml, I can create 1 configmap and 1 secret outside of helm. Then point all my helm instances to this one config/secret. Right now - I think this would only reduce the yaml. Maybe some day it would eliminate it entirely and a --reuse-values could be applied on a very limited per-instance configuration.

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

When branches are created from issues, their pull requests are automatically linked.

2 participants