Helm 3 was released yesterday. Here’s what it means for security pros.
Back to basic- what is Helm?
Helm is the de-facto tool for collaborating when creating, installing, and managing applications inside of Kubernetes.
Specifically it enables Dev teams the following:
- Find prepackaged software (charts) to install and use
- Easily create and host their own packages
- Install packages into any Kubernetes cluster
- Query the cluster to see what packages are installed and running
- Update, delete, rollback, or view the history of installed packages
Over 500 community members have contributed code to the Helm CLI since its inception. Thousands of community members actively maintain charts on the Helm Hub. There are a countless number of active community members.
Helm 3 is here
The most important change in Helm 3 is the removal of Tiller. In Helm, prior to version 3, Tiller was the service that actually communicated with the Kubernetes API server to manage the Helm packages, and was running as an in-cluster service. The removal of Tiller, basically reduced the cluster risk surface.
In addition, a rich set of new features have been added. These include:
- Improving the upgrade strategy into 3-way merge patch,
- Scoping release names at the namespace level,
- Secrets now act as the storage driver for Helm state
- Names are required for installations, collapsing the requirements.yaml into the main chart file, and more
Bye Bye Tiller
With role-based access controls (RBAC) enabled by default in Kubernetes 1.8, locking down Tiller for use in a production scenario became difficult to manage. Unfortunately, this permissive configuration could grant the user a broad range of permissions they weren’t intended to have. DevOps and SREs had to learn additional operational steps when installing Tiller into a multi-tenant cluster. Tiller’s release management system did not need to rely upon an in-cluster operator to maintain state or act as a central hub for Helm release information. Instead, in Helm 3, simply fetch information from the Kubernetes API server, render the Charts client-side, and store a record of the installation in Kubernetes.
With Tiller now gone, the security model for Helm is radically simplified.
By removing Tiller, Helm 3 supports all the modern security, identity, and authorization features of modern Kubernetes. Helm’s permissions are evaluated using the user kubeconfig file. Cluster administrators can restrict user permissions at whatever granularity they see fit. Releases are still recorded in-cluster, and the rest of Helm’s functionality remains.
If there is one thing I’d recommend here: migrate to Helm 3.
Thank you, Helm Community, for introducing this important release, and may our clusters be more secured.