CODEWITHSUNDEEP
kuberneteskubernetes-helm
adelbertc
adelbertc

Reputation: 7320

Best practice for shared K8s Secrets in Helm 3?

I have a couple Charts which all need access to the same Kubernetes Secret. My initial plan was to create a Chart just for those Secrets but it seems Helm doesn't like that. I am thinking this must be a common problem and am wondering what folks generally do to solve this problem?

Thanks!

Upvotes: 1

Views: 1718

Answers (2)

BMW
BMW

Reputation: 45343

Best practice is, don't save any sensitive secrets in kubernetes clusters. kubernetes secret is encode, not encrypt.

You can reference the secret via aws ssm/secrets manager, hashicorp Vault or other similars.

https://github.com/aws-samples/aws-workshop-for-kubernetes/tree/master/04-path-security-and-networking/401-configmaps-and-secrets

Upvotes: 1

Utku Özdemir
Utku Özdemir

Reputation: 7745

Most charts that follow the common chart development practices allow you to use an existing secret instead of creating one for you. This way, you can create your common secrets normally (without helm), and refer to them from the charts that need them, via a reference like existingSecret config key.

Take minio helm chart for example: it accepts an existingSecret key as an alternative to passing an accessKey and a secretKey.

As you can see in the main charts repo, this is a pretty common practice.

Upvotes: 1

Related Questions