Helm has become one the most popular package managers for Kubernetes. The goal of Helm is to help you manage Kubernetes applications using Charts. Helm charts are just "packages" that you can directly install in your Kubernetes cluster. They are really useful since they abstract all the complexity around ConfigMaps, Deployments, Volumes, etc. that otherwise you need to handle one by one, to deploy applications in Kubernetes.
When using Helm in production (i.e. in a Kubernetes cluster with security policies), it's necessary to understand how to properly set up this tool to avoid security issues. In this post, I will walk through some of the security challenges produced by Helm, explaining security best practices to avoid these issues and how Bitnami can help you overcome them with Kubeapps: An open source, web-based UI for deploying and managing applications in Kubernetes.
Helm is very easy to install: once you get the
helm CLI, you just execute a single command:
$ helm init $HELM_HOME has been configured at /home/andres/.helm. Tiller (the Helm server-side component) has been installed in your Kubernetes cluster. Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy. To prevent this, run `helm init` with the --tiller-tls-verify flag. For more information on securing your installation, see: https://docs.helm.sh/using_helm/#securing-your-helm-installation Happy Helming!
So now you are ready to install your favorite applications in Kubernetes! But wait, something else should catch your attention:
Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
That's indeed disturbing. Let's dig into that a little bit more.
Angus Lees, a Bitnami Kubernetes developer, wrote a very detailed article about what the security challenges of Helm are. The main issue is that Helm requires a server side named Tiller. This component is in charge of contacting the Kubernetes API in order to install, on behalf of the user, anything specified in a Helm chart.
This implies that Tiller:
That leads to a now-obvious security issue: escalation of privileges. Suddenly, users with minimum privileges are able to interact with the cluster as if they were administrators. The problem is bigger if a Kubernetes pod gets compromised: that compromised pod is also able to access the cluster as an administrator. That's indeed disturbing.
The official Helm documentation explains a few hints to mitigate these problems. Unfortunately, they don't directly suit this case:
Helm maintainers are aware of the vulnerabilities that having a server side for Helm causes, so in the next major version, they'll get rid of Tiller. If you are curious about what's going to happen with this new version, find the design proposal here. Unfortunately, an official release date is not yet available, so for the time being, it is necessary to stick with the current version 2.
A special mention is deserved for what's called Tillerless Helm, which is about running Tiller in your local host rather than in the Kubernetes cluster. Tiller momentarily runs using the authentication information of the user who executes it, so it's not possible to escalate privileges.
Using this approach has a downside though. You still need to store information about the charts that you install in the cluster. That means that anyone using this solution will need to configure the namespace they are allowed to use, and they will need to run several commands (in different terminals) to deploy a chart. There is a plugin that does this for you, but in any case, this will divert from the default experience.
Kubeapps is a web-based UI for managing applications in Kubernetes clusters. In other words, it allows you to discover and install Helm charts without the
helm CLI, using a web interface.
Kubernetes Role-Based Access Control (RBAC) system backs Kubeapps. This means that to sign in, you need a Kubernetes API token, which is really easy to obtain. Learn how to do so in the getting started guide. Once users are logged in, they will be authenticated as specific Kubernetes users and they won't be able to escalate privileges. To achieve this, we have developed an authorization proxy that validates any action targeting Tiller. This simplified diagram explains how we do it:
With that set-up, it's really easy for users to install Helm charts without the security disadvantages of using a single Tiller for a Kubernetes cluster.
If you are interested in learning how to set up Helm, Tiller, and Kubeapps securely, check out our step-by-step guide.