-
Notifications
You must be signed in to change notification settings - Fork 7
Support templating of output secrets #43
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
Comments
I came here to add this request, so I will instead add my 2c to this issue instead. While the above is better than nothing, I feel something more akin to the way that vault-secrets-operator handles it (see the spec for The ability to do significant transforms, add arbitrary secret key/values, etc are fundamentally basic requirements of this kind of system and if we are to take Secrets Manager seriously in the Corporate space (currently heavily dominated by HashiCorp Vault). While I am trying this out in my HomeLab at the moment, I hope this may evolve in time to be such as a suitable replacement for current tooling. I do feel however that one of the letdowns is in the SecretsManager itself, in that it can only store single key/value pairs not multiple like other solutions, the saving grace for this 1:1 limitation upstream would be a very robust operator making the trade-off more agreeable. |
we have the same problem with traefik as ingress controller where deployments use basic auth as middleware |
+1: I want to be able to annotate the secrets created by the operator. |
It would be great to be able to template the secrets created by the operator in a similar fashion as sealed secrets is supporting. For instance right now you cannot furnish a
dockerconfigjson
as you cannot set the type of the resulting secret. Neither can you add more labels/annotations to be able to hook it into other processes.The text was updated successfully, but these errors were encountered: