This is the seventh and final part of our Helm 3 Preview: Charting Our Future blog series. Read our previous blog post on library charts here. Helm 3.0.0-alpha.1 is the foundation upon which we’ll begin to build the next version of Helm. The features shared over the last few weeks were some of the big promises we made for Helm 3. Many of those features are still in their early stages and that is OK; the idea of an alpha release is to test out an idea, gather feedback from early adopters, and validate those assumptions. Read More…

This is part 6 of 7 of our Helm 3 Preview: Charting Our Future blog series on library charts. You can find our previous blog post on the Helm chart dependencies here. Helm 3 supports a class of chart called a “library chart”. This is a chart that is shared by other charts, but does not create any release artifacts of its own. A library chart’s templates can only declare define elements. Read More…

This is part 5 of 7 of our Helm 3 Preview: Charting Our Future blog series about chart dependencies and some subtle differences between Helm 2 and Helm 3. (Check out our previous blog post on release management here.) Charts that were packaged (with helm package) for use with Helm 2 can be installed with Helm 3, but the chart development workflow received an overhaul, so some changes are necessary to continue developing charts with Helm 3. Read More…

This is part 4 of 7 of our Helm 3 Preview: Charting Our Future blog series on release management. (Check out our previous blog post on the Helm chart repositories here. In Helm 3, an application’s state is tracked in-cluster by a pair of objects: The release object: represents an instance of an application The release version secret: represents an application’s desired state at a particular instance of time (the release of a new version, for example) A helm install creates a release object and a release version secret. Read More…

This is part 3 of 7 of our Helm 3 Preview: Charting Our Future blog series, discussing chart repositories. (Check out our previous blog post on the gentle goodbye to Tiller here.) At a high level, a Chart Repository is a location where Charts can be stored and shared. The Helm client packs and ships Helm Charts to a Chart Repository. Simply put, a Chart Repository is a basic HTTP server that houses an index. Read More…

This is part 2 of 7 of our Helm 3 Preview: Charting Our Future blog series. (Check out our previous blog post on the history of Helm here.) During the Helm 2 development cycle, we introduced Tiller as part of our integration with Google’s Deployment Manager. Tiller played an important role for teams working on a shared cluster - it made it possible for multiple different operators to interact with the same set of releases. Read More…

On October 15th, 2015, the project now known as Helm was born. Only one year later, the Helm community joined the Kubernetes organization as Helm 2 was fast approaching. In June 2018, the Helm community joined the CNCF as an incubating project. Fast forward to today, and Helm 3 is nearing its first alpha release. In this series of seven blog posts over the next four weeks, I’ll provide some history on Helm’s beginnings, illustrate how we got where we are today, showcase some of the new features available for the first alpha release of Helm 3, and explain how we move forward from here. Read More…

We’re beyond excited to share that Helm Summit EU 2019 is now official (h/t to CNCF)! Join the Helm community on September 11 - 12 in Amsterdam, The Netherlands at Pakhuis de Zwijger for our first European Helm Summit. Over the course of two days, we’ll discuss all things Helm and hold tutorials, working sessions, and small group discussions with new and exisiting users. Interested in… Registering? Sign up here before Aug 27 for Early Bird pricing of $250. Read More…

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in ChartMuseum, impacting all versions of ChartMuseum between ChartMuseum >=0.1.0 and < 0.8.1. A specially crafted chart could be uploaded that caused the uploaded archive to be saved outside of the intended location.

When ChartMuseum is configured for multitenancy the specially crafted chart could be uploaded to one tenant but saved in the location of another tenant. This includes overwriting a chart at a version in the other tenant.

Additionally, if ChartMuseum is configured to use a file system the uploaded Chart archive may be uploaded to locations outside of the storage directory. It could be uploaded to any place the ChartMuseum application binary has write permission to.

We are unaware of any public exploits caused by this issue.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in the Helm client, impacting all versions of Helm between Helm >=2.0.0 and < 2.12.2. Two Helm client commands may be coerced into unpacking unsafe content from a maliciously designed chart.

A specially crafted chart may be able to unpack content into locations on the filesystem outside of the chart’s path, potentially overwriting existing files.

No version of Tiller is known to be impacted. This is a client-only issue.

The following Helm commands may unsafely unpack malformed charts onto a local folder: helm fetch --untar and helm lint some.tgz.

We are unaware of any public exploits caused by this issue.