Why Encourage Bad Practices
Why do some Helm charts still want you to put sensitive information in plain text?
I find this particularly vexing when the chart is provided by a well known cloud native organization. To such organizations, the concet of GitOps should not be foreign. In fact I would wager that they themselves make use of GitOps practices within their organization.
So as to not explicitly call out any companies/organizations I will instead present examples of the kinds of issues that I’ve encounted. The first example is deploying a database cluster that requires you to provide a password for the admin user. The next example is creating a server that needs to make use of a private TLS certificate. In both of these examples, you would not want this information (the password or certificate) stored in plain text in your version control system. But the Helm chart will require you to provide a values.yaml file such as
...
auth:
admin_username: admin
admin_password: password
...
The big issue here is that anyone that has access to your repository (whether intended or via a hack) will know all of your passwords.
A better approach would be for the chart to provide an option so that you can instead pass a reference to a Kubernetes secret that contains your password/cerfiticate.
...
auth:
admin_username: admin
admin_password_ref:
secret_name: important_database_credentials
secret_key: password
...
Unfortunately, this isn’t always possible. But if you are using Kustomize to manage deployments to different environments you can make use of the Helm Chart Inflator. This allows Kustomize to create the objects specified by chart. And as an addied benefit you can obtain your secrets file from a secret.
...
helmCharts:
- ...
valuesFrom:
- name: my-secret
path: my-values.yaml
...
This isn’t ideal as you need to store the entire file in the secret, even the non-sensitive portions. But at least this way you can safely pass in your sensitive values.