You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to pass secrets to charts via Credhub, it could be beneficial to consider how a generalized pattern credential references could be used for providers such as Credhub (or SSM, Vault, etc.)
Specifically, my use-case is credhub, but that might not always be the case for my team: looking through the issue backlog shows there's interest in all sorts of provider backends.
Currently, helm secrets (i.e. leverages mozilla/sops) is supported via the secrets: block; during apply, the secrets are decrypted and applied to the deployment. (Sidenote: I've started using this feature, and I love it).
There is an ongoing investigation into using Amazon SSM as a provider, which (appears) to do something similar: during helmfile sync/apply, the credential references are decrypted from the credential manager && the values are passed to the chart.
At the end of the day, from what I understand, all we're really doing is decrypting values && passing them in either as env values or as a decrypted secrets.yaml (helm secrets). But there still remains questions on the best practice for how this can be repeated for different credential providers.
Thanks for the time & consideration. Apologies if this issue is too open-ended, I can tighten it up to only be about Credhub if desired.
The text was updated successfully, but these errors were encountered:
See also: [#662] [#573] [#569] [#41] [#392], and specifically #392 (comment)
In order to pass secrets to charts via Credhub, it could be beneficial to consider how a generalized pattern credential references could be used for providers such as Credhub (or SSM, Vault, etc.)
Specifically, my use-case is credhub, but that might not always be the case for my team: looking through the issue backlog shows there's interest in all sorts of provider backends.
Currently,
helm secrets
(i.e. leveragesmozilla/sops
) is supported via thesecrets:
block; duringapply
, the secrets are decrypted and applied to the deployment. (Sidenote: I've started using this feature, and I love it).There is an ongoing investigation into using Amazon
SSM
as a provider, which (appears) to do something similar: duringhelmfile sync/apply
, the credential references are decrypted from the credential manager && the values are passed to the chart.There are other credential providers which can be used similarly to SSM. E.g., credhub, vault... perhaps even spring cloud config or lastpass or gopass.
At the end of the day, from what I understand, all we're really doing is decrypting values && passing them in either as
env
values or as a decryptedsecrets.yaml
(helm secrets
). But there still remains questions on the best practice for how this can be repeated for different credential providers.Thanks for the time & consideration. Apologies if this issue is too open-ended, I can tighten it up to only be about Credhub if desired.
The text was updated successfully, but these errors were encountered: