-
Notifications
You must be signed in to change notification settings - Fork 67
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
Ability to encrypt only values that are actually secret #202
Comments
Hey @TBeijen! Thanks for raising this issue. I think this is similar to #141 - see the discussion there. I think we should add support for templating mechanism in the init container, similar to Consul Template mechanism. It should solve both that issue and your issue if I understand it correctly. I'll be happy to help you start with a PR :) |
Hi @omerlh, I was aware of #141 but considered it a separate issue, based on the assumption that you would typically like to have the list of key-value pairs that configure an application in the same place (12-factor apps: environment vars or .env files). If #141 would allow specifying template file and destination, taking key-value pairs as input, you have great flexibility to generate basically any type of config file, while still allowing the input of said templating to be lists of key-value pairs. Such key-value pairs in turn, can be easily modified per destination deployment, using e.g. Kustomize (configMapGenerator) or Helmfile. And with this feature you would have maximum readability in your development workflow. I suppose for Summarizing: If |
Sorry, I'm not following - if you'll look on the PR (#204) you'll see that the templating mechanism allows you to do that. Something like:
Isn't that what you're looking for? What else is missing? I'll be happy to understand more about the KamusSecret flow - please open a new issue for that. |
Aha, I missed that PR on #141. Looking at the templating docs there, that looks quite nice indeed. Thanks for taking time to discuss this and the #204 PR! I'll be closing this one. Note to self: Don't discuss GH issues over the course of days in short fragments without proper focus. |
As one of the benefits of a gitops style handling of app definition and configuration, is the ability to review any changes, it would be nice if only the values that are actually secret need to be encrypted.
To illustrate, part of one of our applications .env file contents:
Some possible approaches that spring to mind:
Adding ability to init container to combine encrypted and plain configmaps
Allow opt-in for only decrypting certain values
{kamus{SECRETSECRET}}
, choosing delimiters that go well with base64 encrypted data, and also shouldn't interfere with common templating delimiters.The text was updated successfully, but these errors were encountered: