Manage Auto-generated Secrets In Your Helm Charts
Why?
Helm allows you to pack your Kubernetes applications in a modular way and apply different deployment logic based on users’ configuration “values files”. It’s common that we need to generate random secrets (e.g. JWT / session secrets or random passwords) during the first deployment. We can choose to let our Helm Chart users manually create / manage those secrets outside the Helm Chart deployment lifecycle. But it will be more convenient if the Helm Chart can handle the secret auto-generation. However, it’s not easy to auto-generate and manage those secrets as part of the Helm Charts deployment correctly. This article will talk about the potential issues of some simple solutions and propose a more flexible solution based on Helm’s lookup function.
Create Secrets With Random Functions
Helm provides a list of random string generation functions that allow us to generate cryptographically secure random strings. A simple solution could be to include a template to create a k8s secret object using the randAlphaNum function.
This simple solution seems to look alright. But you will have troubles when you attempt to upgrade your existing deployment later as the template has no idea of the current secret data in the cluster and will always update the secret with a new random value.
Conditionally Create Secret
A better solution could be retrieving the existing secret data and only create the secret with a new value when secret data doesn’t exist.
Here, we will not always set secret data to a randomly generated value anymore. Instead, we will attempt to retrieve the current secret value using the lookup function and only set secret data to a randomly generated value when no existing secret data can be found.
Setting Helm Resource Policy
We now have a solution not only can work with the initial deployment but also with the following upgrades. But as the secret is managed by Helm, it will always be deleted when you delete the Helm deployment. This might not always be the desired behaviour for an auto-generated secret.
For a Helm managed resource, setting resource policy via `helm.sh/resource-policy` annotation to “keep” can prevent the resource from being deleted when the user deletes/uninstall the helm deployment. Here is an example to keep our secret resource after the deletion using the resource policy annotation:
Allow User Supplied Secret
Although we would want to auto-generated the secrets for most cases, we may still want to allow the user to supply their manual created secret to make the solution more flexible.
To achieve this, we can ask the user to supply the manual created secret name via a config field, e.g. .Values.manualSecretName and only render our auto-generated when .Values.manualSecretName is empty.
More on the lookup Function
Helm’s lookup function is a very powerful tool that allows us to apply different deployment logic depends on the cluster state. Because the lookup function requires cluster live state data, please keep in mind it will always return an empty response when you:
- Run your chart with
helm template - Deploy or Upgrade your chart with
--dry-runswitch
Conclusion
It’d be more convenient to make your helm chart auto-generate secrets for your users where it’s appropriate. Using Helm’s lookup function, we can inspect the current state of the cluster in order to create & manage the secret within the Helm Chart in a more reliable & flexible way.
