search

temporalio / helm-charts

Temporal Helm charts
MIT License
276 stars 315 forks source link

Provide a better interface for using existing secrets #515

Open robholland opened 1 week ago

robholland commented 1 week ago

When dealing with secrets we don't currently allow customising the secret key that we use, only the name. The interface that decides whether we should create the secret ourselves is also confusing (you have to set the key name using a different field).

Change this to an interface like:

createSecret: false
secretName: my-secret-name
secretKey: TEMPORAL_POSTGRESQL_PASS

Using createSecret with a default of true should make expected behaviour much clearer.

Discussed in https://github.com/temporalio/helm-charts/discussions/513

Originally posted by **smktpd** June 26, 2024 There is [External Secrets Operator](https://github.com/external-secrets/external-secrets) (ESO) that provides support of `kind: ExternalSecret` CRDs. This is de-facto the best practice of using secrets for Kubernetes payloads that currently exists in the industry. The way it works - is pretty simple: basically, you just apply a manifest with a [SecretStore](https://external-secrets.io/main/api/secretstore/) (or a [ClusterSecretStore](https://external-secrets.io/main/api/clustersecretstore/)) that defines the access to a vault (it supports many kinds of vaults) and an [ExternalSecret](https://external-secrets.io/main/api/externalsecret/) (or [ClusterExternalSecret](https://external-secrets.io/main/api/clusterexternalsecret/)) manifest that describes which secret (exact path and specific key (or all keys from that path)) to read from that vault and which `kind: Secret` to save it to in Kubernetes. It would be nice to make temporal's helm chart have support for it. Bringing support for ExternalSecrets into this chart would require some changes (introduce new values and change the way the secrets are currently mounted into containers).