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
Currently, the values.yaml for both helm charts requires sensitive values such as .Values.env.aws_secret_access_key, ...secre_key, ...pgdb_remote_url, etc. All of these values must be committed to a git repository if you are managing your deployment via GitOps (ArgoCD, FluxCD, etc.) which is not a good solution for anybody.
Many Helm charts solve this problem by supporting an existingSecret value so that any sensitive values can be passed directly to the helm chart (where they are often used to create a Secret), or can be set up in an existing secret (e.g. managed by External Secrets Operator, and simply referenced in the Helm values.
Here are a few examples of charts which do this well:
Actually, it looks like a lot of this work has already begun on the external-secrets branch. Does anyone have context on the state of that effort? it looks to be largely complete but only exists on the plane-ce version develop...external-secrets
Currently, the
values.yaml
for both helm charts requires sensitive values such as.Values.env.aws_secret_access_key
,...secre_key
,...pgdb_remote_url
, etc. All of these values must be committed to a git repository if you are managing your deployment via GitOps (ArgoCD, FluxCD, etc.) which is not a good solution for anybody.Many Helm charts solve this problem by supporting an
existingSecret
value so that any sensitive values can be passed directly to the helm chart (where they are often used to create aSecret
), or can be set up in an existing secret (e.g. managed by External Secrets Operator, and simply referenced in the Helm values.Here are a few examples of charts which do this well:
The text was updated successfully, but these errors were encountered: