0
votes

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!

2
I'm thinking about what kind of secret are you talking about? the secret file can be shared by more than one I just think maybe it should be a config file or in case of sensitive data it could not be the best practice. let me know! - Will R.O.F.

2 Answers

2
votes

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

0
votes

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.