This is the second bonus lesson of Helm Lightning Course. In bonus lessons, we are going to learn some advanced features of Helm. You won’t need these features on a daily basis, but it helps to be aware of them and apply them when needed.
In this lesson, we are going to talk about Helm Plugins — we will learn 3 plugins that are very helpful in real-life Helm usage.
What are plugins
Helm on its own is already a pretty powerful tool combining comprehensive templating features with package and release management, including rollbacks, dry-runs and much. But Helm can’t do everything. To close the gaps in its functionality there are many plugins. You can find most of the most useful plugins in the official Helm documentation.
We are going to install 3 plugins and use them one by one to improve the workflow of using our PGAdmin Helm Chart.
Helm git
Let’s start with helm-git plugin.
Normally, to install Helm Chart, this chart needs be published in a Helm Chart Repository.
This is most often the case for well-maintained community charts, but for internal Charts you might not have your own Chart repository yet.
Or maybe you urgently need the latest changes, that were not yet released to the Chart Repo.
Or maybe you just want to stick with simple git repositories to manage your charts — nothing wrong in this either.
In all of those, and some other cases, you need a way to install Helm Chart directly from the git repository. This is where helm-git plugin becomes useful.
To install it, we need to run helm plugin install and pass a git repository where the plugin is located, plus a version of the plugin. It’s a bit funny that we can easily install plugins from git repositories, but to install charts from git we need to use an extra tool.
Once plugin is installed, we can add our pgadmin chart as a repository. helm-git plugin works well with git repos that hold many different charts, as well as with a repo with only one chart inside — we only need to run helm repo add, followed by repo name — mkdev-pgadmin and then a location of the repo.
That location starts with a git+ prefix in front, followed by a URL to the repository, then an @ sign, followed by a path to the chart inside this git repo — in our case, we leave this empty, as our Chart is located directly in the root of the repository.
helm plugin install https://github.com/aslafy-z/helm-git --version 0.11.1helm repo add mkdev-pgadmin git+https://github.com/mkdev-me/helm-lightning-course.git@
If we list the repositories we have installed, we will see mkdev-pgadmin in the list.
Let’s imagine that this pgadmin Chart was created by someone else, and we simply want to use it. We can install this Chart by running helm install command:
helm install pgadmin mkdev-pgadmin/mkdev-pgadmin
Note that in our case repo name and the chart name are the same, separated by the slash — this is because we only have a single Chart inside our Chart repository, that is also a Git repository.
With the Chart installed, we can move on to the next plugin!
Helm diff
When we installed the chart, we didn’t provide any values file. Now I would like to pass my own values file to upgrade the chart.
env: production
The problem is that I don’t know what will happen when I change the values of a chart. I can use helm template command to render all the templates, but that won’t show me existing objects and how these rendered templates differ from them.
To get a proper diff, I am going to install helm-diff plugin. Let me install it first:
helm plugin install https://github.com/databus23/helm-diff
Now to get a diff between an existing version and the new one, I need to run:
helm diff upgrade pgadmin mkdev-pgadmin/mkdev-pgadmin --values values.production.yaml
I can see that simply changing the env variable, this chart will re-create almost everything. Now I know that I need to be a little more careful with this upgrade.
helm-diff plugin can also compare two different existing releases — this might be handy if you want to see what changed between two deployed versions of your chart. It won’t hurt adding helm-diff to your continuous integration pipeline, so that you can catch potentially disruptive changes before they are merged to the main branch.
Helm secrets
The final and probably most important Helm plugin we will try is called helm secrets.
Helm is perfect for git ops — you can manage all the Kubernetes infrastructure around your application, together with configuration, from a git repository. The only problem is that you can’t do this with the secret information — storing secrets in plain text in a repository is always a bad idea from security perspective.
There are many ways to solve the problem of secret management of Kubernetes applications. For example, there are dedicated cluster components that you can run, like External Secrets Operator or Sealed Secrets Controller. There are also direct integrations with tools like Hashicorp Vault. Tell us in the comments if you want to learn more about those options.
But if you want to avoid running and managing extra tools in your cluster, you can solve the problem with helm secrets plugin.
This plugin allows you to store encrypted secret data in your git repository, and then decrypt it automatically when you install or upgrade your Helm Charts. helm secrets is basically a wrapper around a tool called sops — small open source utility to maintain encrypted files. sops supports many ways to encrypt files, starting from the simple PGP keys, and up to various cloud provider services, like AWS KMS or GCP KMS.
If you remember, together with pgadmin we also installed a whole database. Let’s encrypt the database password and pass it to the pgadmin chart.
We start with installing the helm secrets plugin:
helm plugin install https://github.com/jkroepke/helm-secrets --version v3.12.0
Then we need to install a secret driver. As I mentioned, the default secret driver is sops, though there are a couple of other options, like Hashicorp Vault or vals tool. For now, let’s stick to the default:
https://github.com/mozilla/sops/releases
We are going to use sops with age — a modern encryption tool that is recommended by sops instead of pgp. On Fedora, we can install age with dnf install age -y.
To use age, we need to create an age key:
age-keygen > mkdev.txt
I will now move this keys file to a default location for sops age keys:
cp mkdev.txt ~/.config/sops/age/keys.txt
I will also create a .sops.yaml file which will define default encryption rules for files in this directory. I will use a public recipient id of age key in here:
creation\_rules: - age: 'age1t7yjjt6k77grz82myscdxvf7q2p9mflz37z5pad3gflkgvmwp3rqsj4v29'
Now let’s create a plain text file with a database password inside:
postgresql: postgresqlPassword: secretpass
With the encryption keys configured, I can now encrypt values file by running:
helm secrets enc values.secrets.yaml
helm secrets will replace plain text file with the encrypted version — it’s safe to commit this to a git repository, as long as you don’t keep decryption keys.
To tell Helm that the values file needs to be decrypted, we need to prefix the file name with secrets. Let’s first get a diff — we will see that diff and secrets plugin work nicely together:
helm diff upgrade pgadmin mkdev-pgadmin/mkdev-pgadmin --values secrets://values.secrets.yaml
And now run the upgrade:
helm upgrade pgadmin mkdev-pgadmin/mkdev-pgadmin --values secrets://values.secrets.yamlkubectl get secrets/pgadmin-postgresql -o yaml
If I check the password inside the cluster, I will see that it has the proper value:
kubectl get secrets/pgadmin-postgresql -o yaml
Conclusion
We just looked at 3 helm plugins: helm-git, helm-diff and helm-secrets. With those 3 plugins, you can build powerful development and deployment workflows, that are more reliable and secure. While Helm on it’s own is a very powerful tool, with additional plugins it becomes even more pleasant to use for production use cases.
Here's the same article in video form for your convenience:
.
Top comments (0)