Helm may be a popular solution, but not necessarily a safe one

Kubernetes deployments are managed through declarative configuration files. Each file typically describes a type of resource, like pods, containers, and secrets. Specifying deployments can be cumbersome, especially for complex setups.

Helm is a package manager that aims to simplify this process, by assembling Kubernetes configuration files into what are known as charts: packages that can be shared for reuse. Helm makes it possible to install, update, and uninstall charts with a single command.

This week’s paper provides insights about the current state of the ecosystem that is forming around Helm charts, and its evolution over time. The study’s results are based on analysis of publicly available charts on Artifact Hub, a centralised index that enables users to search for charts across various repository providers.

The first Helm chart was created in October 2016. Since then the number of published charts has increased exponentially, surpassing 10,000.

Helm charts are versioned using SemVer (X.Y.Z or Major.Minor.Patch). Most chart releases (77.5%) are patch releases, while 16.5% are minor releases. Only 4% of chart releases are major releases. Interestingly, more than half of all charts have never changed their major version number since their creation, which means that they are still in major version 0 (0.Y.Z). This is the case for 36.8% of all verified charts and 56.2% of all unverified charts.

Most charts are declared as applications (53%), while less than 1% are explicitly declared as a library that can be reused in other charts. The remaining 46% do not have any classification and could be either applications or libraries.

The researchers also found that most Helm charts do not have a software license, which may cause legal issues when deployed. The charts that are accompanied by a license, tend to use permissive licenses like Apache-2.0 and MIT.

Few charts are popular. 81% of charts have not received any star, 92% do not have any subscribers and 97% do not have any production users. It is unclear whether this means that only a very small portion of charts enjoy widespread use or that these numbers simply do not reflect real-world popularity.

The majority of charts (64%) includes the name and email of their maintainers in the Chart.yaml file. Each chart has, on average and median, a single maintainer. This makes chart reuse potentially risky, especially if the listed maintainer is an individual (side note: Maintainers can also be organisations like Bitnami.): once a chart is abandoned it no longer receives bug fixes and vulnerability patches, and may configure Kubernetes in a suboptimal or outdated manner.

Less than a third of all charts have dependencies on other charts. Developers can specify version constraints, like 1.2.3 or ^1.2.3, to restrict the versions a chart depends on. Most charts use strict version constraints so that they cannot be updated automatically. This makes it easier for charts to become outdated.

Helm charts are often used to deploy container images to a Kubernetes cluster. More than half of charts only use a single image, which often comes from Docker Hub (60%), GitHub (17%) or Quay (6%). Most (89%) charts declare the use of a specific version of an image, e.g. node:19.4.0-alpine3.17. Although considered a Docker best practice, this approach increases the likelihood of charts becoming outdated if not actively updated.

Further analysis of the Helm charts shows that charts often are indeed outdated. At the time of analysis, 57% of the images declared in charts were outdated. On average, these images lagged almost an entire year behind the latest versions in container registries. Even more concerning, 41% of images were already outdated at the time of the charts’ release. At the same time, charts that were published recently tend to use more up-to-date images, as do charts that are verified.

Alarmingly, as many as 9 out of 10 Helm charts deploy at least one vulnerability. On average, each chart contains 510 different vulnerabilities. Most of these vulnerabilities are of medium or high severity. Approximately 9% of vulnerabilities are of a critical severity, such as Spring4Shell (CVE-2022-22965).