1"use strict";(self.webpackChunkhelm_www=self.webpackChunkhelm_www||[]).push([["36607"],{77735(e){e.exports=JSON.parse('{"archive":{"blogPosts":[{"id":"helm-v3-end-of-life","metadata":{"permalink":"/blog/helm-v3-end-of-life","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2026-06-02-helm3-eol.md","source":"@site/blog/2026-06-02-helm3-eol.md","title":"Helm 3 End of Life","description":"Helm 3 is approaching end-of-life. A final, limited Helm 3 feature release will be September 9th, 2026, with security patches continuing to be provided through February 2027.","date":"2026-06-02T00:00:00.000Z","tags":[],"readingTime":4.96,"hasTruncateMarker":true,"authors":[{"name":"George Jenkins","page":{"permalink":"/blog/authors/georgejenkins"},"socials":{"github":"https://github.com/gjenkins8"},"imageURL":"https://github.com/gjenkins8.png","key":"georgejenkins"}],"frontMatter":{"title":"Helm 3 End of Life","slug":"helm-v3-end-of-life","authors":["georgejenkins"],"date":"2026-06-02"},"unlisted":false,"nextItem":{"title":"Security Notice: Former Helm APT Mirror Domain `baltocdn.com` Statement","permalink":"/blog/security-notice-baltocdn"}},"content":"Helm 3 is approaching end-of-life. A final, limited Helm 3 feature release will be **September 9th, 2026**, with security patches continuing to be provided through February 2027.\\n\\nWith the successful release of Helm 4 in November 2025, the maintainers and community are now focused on enhancing the functionality of Helm 4. If you haven\'t started evaluating Helm 4, now is the time.\\n\\nHelm 4 offers several improvements over Helm 3 (detailed below), and is expected to be compatible with the majority of existing Helm 3 charts, releases, and workflows.\\n\\n\x3c!-- truncate --\x3e\\n\\n## Helm 3 End of Life Timeline\\n\\nThe [Helm 4 Released](/blog/helm-4-released) announcement outlined the original Helm 3 support schedule following the Helm 4.0.0 release in November 2025. However, the Helm maintainers have **decided to create one extra (limited) feature release on September 9th, 2026** and **extend security support to February 10th, 2027** - three months beyond the original timelines.\\n\\nThe Helm 4 development cycle and Helm 3 support timeline was originally documented in [HIP-0012: Helm 4 Development Process: Maintaining Helm 3](/community/hips/hip-0012#maintaining-helm-3).\\n\\nThe updated timeline is as follows:\\n\\n- **Bug fixes** up to the final feature release, September 9th, 2026.\\n- **Final feature release**: September 9th, 2026 \u2014 this will be the last Helm 3 minor release, limited to Kubernetes client library updates for new Kubernetes version support. No other new features will be backported.\\n- **Security fixes** end February 10th, 2027 (extended from November 2026).\\n\\nAfter February 2027, Helm 3 will no longer receive any updates: *including Kubernetes client library and security patches*. We strongly encourage all users to migrate to Helm 4 before that date.\\n\\n## Why Helm 4\\n\\nHelm 3 served the Kubernetes community well for over six years. During that time, the project accumulated technical debt and hit architectural limits that prevented new features from being introduced without breaking the SDK\'s public APIs. Helm 4 addresses this with breaking changes that enable the project to move forward, while maintaining significant backwards compatibility with the majority of existing workflows.\\n\\nFor full details, see [HIP-0012: Helm 4 Development Process](/community/hips/hip-0012).\\n\\n> Charts deployable with Helm 3 should be deployable by Helm 4. Similarly, any existing chart (release) managed by Helm 3 generally should be upgradable by Helm 4.\\n\\nThis means you can upgrade the Helm binary without rewriting your charts or redeploying your releases. CLI workflows are also largely preserved - most users should experience little to no changes required.\\n\\n## What\'s New in Helm 4\\n\\nHere is an overview of the key changes. For full details, see the [Helm 4 Overview](/docs/overview).\\n\\n### New Features\\n\\n- **Plugin system overhaul** \u2014 An optional WebAssembly-based plugin runtime with enhanced
1security. Existing plugins continue to work. Three plugin types ship with Helm 4: CLI, getter, and post-renderer plugins, plus an extensible system for new plugin types. See [HIP-0026](/community/hips/hip-0026) for details.\\n- **Better resource monitoring** \u2014 [kstatus](https://helm.sh/community/hips/hip-0022/) integration provides detailed deployment status tracking.\\n- **Multi-document values** \u2014 Split values across multiple YAML files for environment-specific configurations.\\n- **Server-side apply** \u2014 Default for new releases, with automatic latching to client-side apply for upgrades of existing Helm 3 releases.\\n- **Custom template functions** \u2014 Extend Helm\'s templating through plugins.\\n- **Stable SDK API** \u2014 API breaking changes are complete, enabling Charts v3 development.\\n\\n### Breaking Changes\\n\\n- **Post-renderers are plugins** \u2014 `helm install --post-renderer` now takes a plugin name, not an executable path. Update any existing post-renderer workflows.\\n- **Registry login scoped to domain** \u2014 `helm registry login` accepts domain names only (not full URLs), enabling future per-scope login.\\n- **CLI flag renames** \u2014 `--atomic` is now `--rollback-on-failure` and `--force` is now `--force-replace`. The old flags still work but emit deprecation warnings.\\n\\n### Improvements\\n\\n- Faster dependency resolution and content-based chart caching.\\n- Clearer error messages.\\n- Better OAuth and token support for private registries.\\n\\n## Helm 3 Security Patch Release\\n\\n[HIP-0012](/community/hips/hip-0012) originally specified security fixes for one year from the Helm 4.0.0 release \u2014 through November 2026. The Helm maintainers are extending this by three months to **February 10th, 2027**, giving the community more time to complete the migration to Helm 4.\\n\\nDuring this security-only maintenance window:\\n\\n- **No new features** will be backported to Helm 3, including updates to Kubernetes client libraries.\\n- **Only security patches** will be released (on demand / as needed).\\n- **No bug fixes** will otherwise be applied.\\n\\nIf a security vulnerability is discovered in Helm 3 before February 2027, a patch release will be issued. After February 10th, 2027, no further Helm 3 releases of any kind will be made.\\n\\n## Migrating to Helm 4\\n\\nThe upgrade path is designed to be straightforward. The following steps can be used to make your migration journey as smooth as possible:\\n\\n1. **Test your charts** \u2014 Deploy your existing charts with Helm 4 in a non-production environment\\n2. **Test your CI/CD pipelines** \u2014 Update any scripts using renamed CLI flags (`--atomic` \u2192 `--rollback-on-failure`, `--force` \u2192 `--force-replace`)\\n3. **Test post-renderer workflows** \u2014 Migrate any `--post-renderer` usage to the new plugin system\\n4. **Test registry authentication** \u2014 Verify OCI workflows with `helm registry login` using domain names only\\n5. **Upgrade** \u2014 Helm 4 can manage existing Helm 3 releases without any migration steps\\n - To note: Helm 4 will default to server-side apply when installing a new Chart release. When upgrading (or rolling back), Helm will by default follow the previous apply method of the release. This latching behavior can be overridden by explicitly setting `--server-side=false`.\\n\\nFor the full upgrade checklist, see the [Upgrading to Helm 4](/docs/overview#upgrading-to-helm-4) section of the documentation.\\n\\n## Get Involved\\n\\n- **GitHub Issues**: [helm/helm](https://github.com/helm/helm/issues)\\n- **Kubernetes Slack**: [#helm-dev](https://kubernetes.slack.com/archives/C51E88VDG) and [#helm-users](https://kubernetes.slack.com/archives/C0NH30761)\\n- **Weekly Dev Meetings**: Thursdays 9:30am PT on [Zoom](https://zoom-lfx.platform.linuxfoundation.org/meeting/91295593969?password=17825db5-c698-44cc-9f00-ef1f61f5d3fb)\\n\\nFor more details, see the [community communication guide](/community/communication)."},{"id":"security-notice-baltocdn","metadata":{"permalink":"/blog/security-notice-baltocdn","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2026-05-29-security-notice-baltocdn.md","source":"@site/blog/2026-05-29-security-notice-baltocdn.md","title":"Security Notice: Former Helm APT Mirror Domain `baltocdn.com` Statement","description":"The Helm Security Team has received third-party reports that the ownership on the former community-maintained Debian/Ubuntu APT mirror domain, baltocdn.com, has changed after baltocdn.com\'s original registration lapsed.","date":"2026-05-29T00:00:00.000Z","tags":[],"readingTime":3.71,"hasTruncateMarker":true,"authors":[{"name":"George Jenkins","page":{"permalink":"/blog/authors/georgejenkins"},"socials":{"github":"https://github.com/gjenkins8"},"imageURL":"https://github.com/gjenkins8.png","key":"georgejenkins"},{"name":"Andrew Block","page":{"permalink":"/blog/authors/andrewblock"}
1,"socials":{"github":"https://github.com/sabre1041","linkedin":"https://www.linkedin.com/in/andrewsblock/","website":"https://t.co/utJRRBeHm1"},"imageURL":"https://github.com/sabre1041.png","key":"andrewblock"}],"frontMatter":{"title":"Security Notice: Former Helm APT Mirror Domain `baltocdn.com` Statement","slug":"security-notice-baltocdn","authors":["georgejenkins","andrewblock"],"date":"2026-05-29"},"unlisted":false,"prevItem":{"title":"Helm 3 End of Life","permalink":"/blog/helm-v3-end-of-life"},"nextItem":{"title":"Helm 4 Released","permalink":"/blog/helm-4-released"}},"content":"The Helm Security Team has received third-party reports that the ownership on the former community-maintained Debian/Ubuntu APT mirror domain, `baltocdn.com`, has changed after `baltocdn.com`\'s original registration lapsed.\\nAnd as a result, the new owners may be using the domain to serve malicious content.\\n\\n\x3c!-- truncate --\x3e\\n\\nWe are publishing this notice to raise awareness for Helm users who may still have the configuration of their APT package manager referencing `baltocdn.com`.\\n`baltocdn.com` was previously used as the APT mirror for Helm distribution for many years, but it is no longer a Helm APT mirror, and must not be used to manage Helm.\\n\\n## Summary\\n\\nThe former Helm APT mirror domain `baltocdn.com` was decommissioned in September 2025.\\nSince decommissioning, attempts to access or download Helm packages from `baltocdn.com` should have failed due to the underlying serving infrastructure having been shut down.\\n\\nThe domain registration for `baltocdn.com` later expired and the domain was re-registered by a [third party](https://www.dynadot.com/domain/whois?domain=baltocdn.com) on May 19, 2026. As a result, users, systems, or automation still attempting to download Helm packages from `baltocdn.com` could be directed to content controlled by the new domain registrant.\\n\\nAt this time, the Helm Security Team has received third-party reports that the domain may have been repurposed to serve malicious content. We have not independently confirmed those reports. However, as the domain is no longer controlled by the previous APT repository operator and is no longer a Helm distribution endpoint, any continued use of `baltocdn.com` represents a potential supply chain risk.\\n\\n## Affected users\\n\\nYou may be affected if any Debian or Ubuntu based systems, APT repositories, CI jobs, container images, installation scripts, bootstrap scripts, configuration management templates, or internal documentation still reference:\\n\\n`baltocdn.com`\\n\\nAny user who executed binaries sourced from `baltocdn.com` after May 19, 2026 should consider the affected system compromised and follow their normal incident response procedures.\\n\\nUsers who have legacy references to `baltocdn.com` but have not attempted to install or update Helm from that domain after May 19, 2026 should still remove those references immediately using the steps below.\\n\\n## **Remediation**\\n\\nPlease ensure that all Debian/Ubuntu APT-based Helm installations use the current APT repository:\\n\\n[https://packages.buildkite.com/helm-linux/helm-debian](https://packages.buildkite.com/helm-linux/helm-debian)\\n\\nReview your systems and repositories for any remaining references to `baltocdn.com` and replace them with the current installation instructions.\\n\\nThe current Helm APT installation instructions are available at the link below:\\n\\n[https://helm.sh/docs/intro/install/\\\\#from-apt-debianubuntu](https://helm.sh/docs/intro/install/#from-apt-debianubuntu)\\n\\nRecommended actions:\\n\\n1. Remove any APT source entries that reference `baltocdn.com`.\\n2. Update Debian/Ubuntu APT-based Helm installation configuration to use `packages.buildkite.com`.\\n3. Review CI/CD pipelines, Dockerfiles, bootstrap scripts, configuration management, and internal documentation for legacy references.\\n4. Treat any system that executed binaries sourced from `baltocdn.com` after May 19, 2026 as potentially compromised.\\n5. Follow your organization\u2019s incident response process if you believe a system may have downloaded or executed content from the repurposed domain.\\n6. Disable access (corporate proxy/firewall, etc) to `baltocdn.com`. Since the site was previously decommissioned and no longer serving content related to the Helm project, limiting access will not break existing workflows.\\n\\n## About the Helm APT repository\\n\\nThe Helm Debian/Ubuntu APT [repository](https://packages.buildkite.com/helm-linux/helm-debian/) (and its `baltocdn.com` predecessor) is gratefully community maintained. It is not directly supported by the Helm maintainers.\\n\\nThe Helm project provides official methods for installing Helm from binary releases and from the Helm install script. Community-provided package manager installation methods, including APT, are documented for user convenience but are not directly supported by the Helm project.\\n\\n## Engage with the Helm Community\\n\\nThe Helm project provides multiple ways to interact with the community which include Slack channels and the weekly developers meeting. Members of the Helm security team and maintainers are present within these forums and, along with the rest of the community, can address questions or concerns related to Helm related topics.\\n\\n## Reporting security concerns\\n\\nFor more information about reporting security concerns associated with the Helm project, please see the Helm Security Process and Policy documentation:\\n\\n[https://helm.sh/community/security/](https://helm.sh/community/security/)\\n\\n## Conclusion\\n\\n`baltocdn.com` is no longer a Helm APT mirror and should not be used to install and manage Helm.\\nUsers should migrate any remaining Debian/Ubuntu APT-based Helm installation configuration to `packages.buildkite.com` and review their environments for legacy references to the former domain to mitigate potential security concerns."},{"id":"helm-4-released","metadata":{"permalink":"/blog/helm-4-released","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2025-11-17-helm-4-released/index.md","source":"@site/blog/2025-11-17-helm-4-released/index.md","title":"Helm 4 Released","description":"On Wednesday November 12th, during the Helm 4 presentation at KubeCon + CloudNativeCon, Helm v4.0.0 was released. This is the first new major version of Helm in 6 years.","date":"2025-11-17T00:00:00.000Z","tags":[],"readingTime":1.81,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm 4 Released","slug":"helm-4-released","authors":["mattfarina"],"date":"2025-11-17"},"unlisted":false,"prevItem":{"title":"Security Notice: Former Helm APT Mirror Domain `baltocdn.com` Statement","permalink":"/blog/security-notice-baltocdn"},"nextItem":{"title":"Helm @ KubeCon + CloudNativeCon NA \'25","permalink":"/blog/helm-at-kubecon-na-25"}},"content":"On Wednesday November 12th, during the [Helm 4 presentation at KubeCon + CloudNativeCon](https://sched.
1co/27Nme), [Helm v4.0.0](https://github.com/helm/helm/releases/tag/v4.0.0) was released. This is the first new major version of Helm in 6 years. \x3c!-- truncate --\x3e\\n\\n## What\'s New\\n\\nHelm v3 has served the Kubernetes community well for many years. During that time we saw new ways to use Helm, new applications installed via charts, the rise of [Artifact Hub](https://artifacthub.io/), and numerous tools that build on top of Helm. We also saw where we wanted to add features but the internal architecture of Helm didn\'t provide a path forward without breaking public APIs in the SDK. Helm 4 makes those changes to enable new features now and into the future.\\n\\nSome of the new features include:\\n\\n- Redesigned plugin system that supports Web Assembly based plugins\\n- Post-renderers are now plugins\\n- Server side apply is now supported\\n- Improved resource watching, to support waiting, based on kstatus\\n- Local Content-based caching (e.g. for charts)\\n- Logging via slog enabling SDK logging to integrate with modern loggers\\n- Reproducible/Idempotent builds of chart archives\\n- Updated SDK API including support for multiple chart API versions (new experimental v3 chart API version coming soon)\\n\\nYou can learn about more of the changes in the [Helm 4 Overview](/docs/overview).\\n\\n## Helm v3 Support\\n\\nWhen a major version of software comes out, it takes awhile to make the transition. Helm v3 will continue to be supported to enable a clean transition period. The dates of continued support are:\\n\\n* Bug fixes until July 8th 2026.\\n* Security fixes until November 11th 2026.\\n\\nHelm releases updates on Wednesdays (typically the 2nd Wednesday in a month) and these dates correspond with release schedule dates. During this time there will be **_NO_** features backported other than updates to the Kubernetes client libraries that enable support of new Kubernetes versions.\\n\\n## Learn More\\n\\nYou can learn about the Helm changes in the [overview](/docs/overview) or find all the changes in the [full changelog](/docs/changelog). The documentation shares many more details as you can find all the ways Helm has stayed the same and the new features you can take advantage of."},{"id":"helm-at-kubecon-na-25","metadata":{"permalink":"/blog/helm-at-kubecon-na-25","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2025-11-04-helm-at-kubecon-na-25.md","source":"@site/blog/2025-11-04-helm-at-kubecon-na-25.md","title":"Helm @ KubeCon + CloudNativeCon NA \'25","description":"The Helm team is headed to KubeCon + CloudNativeCon NA \'25 in Atlanta, Georgia next week and it\'s truly a special one for us! This time around, as we celebrate our 10th birthday (fun fact, Helm was launched at the first KubeCon in 2015), we will also be releasing the highly anticipated Helm 4! Join us for a series of exciting activities throughout the week -- read on for more details!","date":"2025-11-04T00:00:00.000Z","tags":[],"readingTime":4.61,"hasTruncateMarker":true,"authors":[{"name":"Karen Chu","page":{"permalink":"/blog/authors/karenchu"},"socials":{"github":"https://github.com/karenhchu","linkedin":"https://www.linkedin.com/in/karenhchu/"},"imageURL":"https://github.com/karenhchu.png","key":"karenchu"}],"frontMatter":{"title":"Helm @ KubeCon + CloudNativeCon NA \'25","slug":"helm-at-kubecon-na-25","authors":["karenchu"],"date":"2025-11-04"},"unlisted":false,"prevItem":{"title":"Helm 4 Released","permalink":"/blog/helm-4-released"},"nextItem":{"title":"Helm Turns 10","permalink":"/blog/helm-turns-ten"}},"content":"The Helm team is headed to KubeCon + CloudNativeCon NA \'25 in Atlanta, Georgia next week and it\'s truly a special one for us! This time around, as we celebrate our 10th birthday (fun fact, Helm was launched at the first KubeCon in 2015), we will also be releasing the highly anticipated Helm 4! Join us for a series of exciting activities throughout the week -- read on for more details! \\n\\n\x3c!-- truncate --\x3e\\n\\n## Helm Booth in Project Pavilion\\n\\nDon\'t miss out on meeting our project maintainers at the Helm booth - we\'ll be hanging out the second half of each day. Drop by to ask questions, learn about what\'s in Helm 4, and pick up special Hazel swag celebrating Helm\'s 10th birthday!\\n\\n* TUES Nov 11 @ 03:30 PM - 07:45 PM ET \\n\\n* WED Nov 12 @ 02:00 PM - 05:00 PM ET\\n\\n* THUR Nov 13 @ 12:30 PM - 02:00 PM ET\\n\\nLOCATION: 8B, back side of Flux and across from Argo\\n\\n## Tuesday November 11, 2025\\n\\n### [Simplifying Advanced AI Model Serving on Kubernetes Using Helm Charts](https://sched.
1co/27FVb)\\n\\nTIME: 12:00 PM - 12:30 PM ET\\n\\nLOCATION: Building B | Level 4 | B401-402\\n\\nSPEAKERS: [Ajay Vohra](https://kccncna2025.sched.com/speaker/ajayvohr) & [Caron Zhang](https://kccncna2025.sched.com/speaker/caronzh03)\\n\\nThe AI model serving landscape on Kubernetes presents practitioners with an overwhelming array of technology choices: From inference servers like Ray Serve and Triton Inference Server, inference engines like vLLM, and orchestration platforms like Ray Cluster and KServe. While this diversity drives innovation, it also creates complexity. Teams often prematurely standardize on limited technology stacks to manage this complexity.\\n\\nThis talk introduces an innovative Helm-based approach that abstracts the complexity of AI model serving while preserving the flexibility to leverage the best tools for each use case. Our solution is accelerator agnostic, and provides a consistent YAML interface for deploying and experimenting with various serving technologies.\\n\\nWe\'ll demonstrate this approach through two concrete examples of multi-node, multi-accelerator model serving with auto scaling: 1/ Ray Serve + vLLM + Ray Cluster, and 2/ LeaderWorkerSet + Triton Inference Server + vLLM + Ray Cluster + HPA.\\n\\n## Wednesday November 12, 2025\\n\\n### [Maintainer Track: Introducing Helm 4](https://sched.co/27Nme)\\n\\nTIME: 11:00 AM - 11:30 AM ET\\n\\nLOCATION: Building C | Level 3 | Georgia Ballroom 1\\n\\nSPEAKERS: [Matt Farina](https://kccncna2025.sched.com/speaker/matt812) & [Robert Sirchia](https://kccncna2025.sched.com/speaker/robert_sirchia.28kd1wis) (Helm Maintainers)\\n\\nThe wait is over! After six years with Helm v3, Helm v4 is finally here. In this session you\'ll learn about Helm v4, why there was 6 years between major versions (from backwards compatible feature development to maintainer ups and downs), what\'s new in Helm v4, how long Helm v3 will still be supported, and what comes next. Could that include a Helm v5?\\n\\n### [Contribfest: Hands-On With Helm 4: Wasm Plugins, OCI, and Resource Sequencing. Oh My!](https://sched.co/27Nl0)\\n\\nTIME: 02:15pm - 03:30 PM ET\\n\\nLOCATION: Building B | Level 2 | B207\\n\\nSPEAKERS: [Andrew Block](https://kccncna2025.sched.com/speaker/ablock2), [Scott Rigby](https://kccncna2025.sched.com/speaker/r6by), & [George Jenkins](https://kccncna2025.sched.com/speaker/gvjenkins) (Helm Maintainers)\\n\\nJoin Helm maintainers for an interactive session contributing to core Helm and building integrations with some of Helm 4\'s emerging features. We\'ll guide contributors through creating Helm 4\'s newest enhancements including WebAssembly plugins, enhancements to how OCI content is manged, and implementing resource sequencing for controlled deployment order. Attendees will explore how to build Download/Postrender/CLI plugins in WebAssembly, develop capabilities related to changes to Helm\'s management of OCI content including repository prefixes and aliases, and use approaches for sequencing chart deployments beyond Helm\'s traditional mechanisms.\\n\\nThis session is geared toward anyone interested in Helm development including leveraging and building upon some of the latest features associated with Helm 4!\\n\\n### [Helm 4 Release Party](/helm-4-release-party/)\\n\\nTIME: 06:00 PM - 09:00 PM EST\\n\\nLOCATION: [Max Lager\'s Wood-Fired Grill & Brewery](https://www.google.com/maps/place/Max+Lager\'s+Wood-Fired+Grill+%26+Brewery/@33.7633384,-84.3869351,16z/data=!3m1!4b1!4m6!3m5!1s0x88f50479f0b45fe9:0x8c53b75958299abd!8m2!3d33.7633384!4d-84.3869351!16s%2Fm%2F01_23gr)\\n\\n[Replicated](https://www.replicated.com/) and the [CNCF](https://www.cncf.io/) are throwing a Helm 4 Release Party to celebrate the release of Helm 4! Drop by for a low country boil and hang out with the Helm project maintainers for the night! See the invitation [here](/helm-4-release-party/), and don\'t forget to save your spot \u2013 RSVP [here](https://replicated.typeform.com/helmparty).\\n\\n## Thursday November 13, 2025\\n\\n### [Mission Abort: Intercepting Dangerous Deletes Before Helm Hits Apply](https://sched.
1co/27FeJ)\\n\\nTIME: 01:45 PM - 02:15 PM ET\\n\\nLOCATION: Building B | Level 5 | Thomas Murphy Ballroom 4\\n\\nSPEAKERS: [Payal Godhani](https://kccncna2025.sched.com/speaker/godhanipayal)\\n\\nWhat if your next Helm deployment silently deletes a LoadBalancer, a Gateway, or an entire namespace? We\u2019ve lived that nightmare\u2014multiple times. In this talk, we\u2019ll share how we turned painful Sev1 outages into a resilient, guardrail-first deployment strategy. By integrating Helm Diff and Argo CD Diff, we built a system that scans every deployment for destructive changes\u2014like the removal of LoadBalancers, KGateways, Services, PVCs, or Namespaces\u2014and blocks them unless explicitly approved. This second-layer approval acts as a safety circuit for your release pipelines. No guesswork. No blind deploys. Just real-time visibility into what\u2019s about to break\u2014before it actually does. Whether you\u2019re managing a single cluster or an entire fleet, this talk will show you how to stop fearing Helm and start trusting it again. Because resilience isn\u2019t about avoiding failure\u2014it\u2019s about learning, adapting, and building guardrails that protect everyone."},{"id":"helm-turns-ten","metadata":{"permalink":"/blog/helm-turns-ten","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2025-10-19-helm-turns-10/index.md","source":"@site/blog/2025-10-19-helm-turns-10/index.md","title":"Helm Turns 10","description":"Ten years ago, in a hackathon shortly after the release of Kubernetes 1.1.0, Helm was born.","date":"2025-10-19T00:00:00.000Z","tags":[],"readingTime":0.64,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm Turns 10","slug":"helm-turns-ten","authors":["mattfarina"],"date":"2025-10-19"},"unlisted":false,"prevItem":{"title":"Helm @ KubeCon + CloudNativeCon NA \'25","permalink":"/blog/helm-at-kubecon-na-25"},"nextItem":{"title":"Path To Releasing Helm v4","permalink":"/blog/path-to-helm-v4"}},"content":"Ten years ago, in a hackathon shortly after the release of Kubernetes 1.1.0, Helm was born.\\n\\n```\\ncommit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d\\nAuthor: Matt Butcher <[email protected]>\\nDate: Mon Oct 19 17:43:26 2015 -0600\\n\\n initial add\\n```\\n\x3c!-- truncate --\x3e\\n\\n[The first commit](https://github.com/helm/helm-classic/commit/ecad6e2ef9523a0218864ec552bbfc724f0b9d3d) can be found on the helm-classic Git repository where the codebase for Helm v1 is located. This is the original Helm, before it merged with Deployment Manager and was folded into the Kubernetes project.\x3c!--more--\x3e\\n\\nThis commit was just the beginning. Helm would be shown off at the first KubeCon, just a few weeks later. From there Helm development would take off and a community of developers and charts would follow.\\n\\nHappy 10th Birthday, Helm!\\n\\n"},{"id":"path-to-helm-v4","metadata":{"permalink":"/blog/path-to-helm-v4","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2025-09-09-path-to-helm-v4.md","source":"@site/blog/2025-09-09-path-to-helm-v4.md","title":"Path To Releasing Helm v4","description":"The first Alpha for Helm v4 has been released. Now that Helm v4 development is in the home stretch, we wanted to share the details on what\'s happening and how the broader community can get involved.","date":"2025-09-09T00:00:00.000Z","tags":[],"readingTime":1.63,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Path To Releasing Helm v4","slug":"path-to-helm-v4","authors":["mattfarina"],"date":"2025-09-09"},"unlisted":false,"prevItem":{"title":"Helm Turns 10","permalink":"/blog/helm-turns-ten"},"nextItem":{"title":"Debian/Ubuntu Helm Apt Repository Move","permalink":"/blog/debian-helm-repository-move"}},"content":"The [first Alpha for Helm v4](https://github.com/helm/helm/releases/tag/v4.0.0-alpha.1) has been released. Now that Helm v4 development is in the home stretch, we wanted to share the details on what\'s happening and how the broader community can get involved.\x3c!-- truncate --\x3e\\n\\n## Alpha Period\\n\\nWith the start of September, there is a freeze on new major features for Helm v4. This begins the Alpha phase, where API breaking changes will still happen, but the focus turns to stability and making sure the existing changes work as expected.\\n\\nIf you\'re a Helm user, during this period you can test out the current capabilities and provide feedback where things aren\'t working as expected. Just remember, this is alpha quality software and changes are still occurring.\\n\\nFor Helm SDK users, now is a good time to look at the API to see if there are any concerns with the design changes along with any impacts to your efforts.\\n\\nThe Alpha period runs through the month of September.\\n\\n## Beta Period\\n\\nThe beta period starts in October. At this point the focus is on stability in preparation for release. API breaking changes should be complete and the focus transitions to fixing any bugs to ensure there is a stable release.\\n\\nTesters should file bugs as they encounter any issues.\\n\\nPer [release schedule policy](/community/release_policy#major-releases), once the first beta version is available, the final 4.0.0 release date will be chosen and announced.\\n\\n## Release Candidates\\n\\nAt the end of October, the first release candidate will be created. This represents what we think will be released as Helm v4. If there are any major issues, they will be fixed and a new release candidate will be made.\\n\\n## \u{1F389} Release \u{1F389}\\n\\nThe release is planned for KubeCon + CloudNativeCon North America 2025. in mid November, which is 6 years after the release of Helm v3 and 10 years after the creation of Helm. More details on the release will c
1ome."},{"id":"debian-helm-repository-move","metadata":{"permalink":"/blog/debian-helm-repository-move","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2025-08-19-debian-helm-repository-move.md","source":"@site/blog/2025-08-19-debian-helm-repository-move.md","title":"Debian/Ubuntu Helm Apt Repository Move","description":"If you are installing helm with Apt, be aware that the Debian/Ubuntu Helm Apt repository is moving.","date":"2025-08-19T00:00:00.000Z","tags":[],"readingTime":0.3,"hasTruncateMarker":true,"authors":[{"name":"Terry Howe","page":{"permalink":"/blog/authors/terryhowe"},"socials":{"github":"https://github.com/terryhowe","linkedin":"https://www.linkedin.com/in/terrylhowe/","website":"https://terryhowe.wordpress.com/"},"imageURL":"https://github.com/terryhowe.png","key":"terryhowe"}],"frontMatter":{"title":"Debian/Ubuntu Helm Apt Repository Move","slug":"debian-helm-repository-move","authors":["terryhowe"],"date":"2025-08-19"},"unlisted":false,"prevItem":{"title":"Path To Releasing Helm v4","permalink":"/blog/path-to-helm-v4"},"nextItem":{"title":"Helm @ KubeCon + CloudNativeCon EU \'25","permalink":"/blog/helm-at-kubecon-eu-25"}},"content":"If you are installing helm with Apt, be aware that the Debian/Ubuntu Helm Apt repository is moving.\x3c!-- truncate --\x3e\\nPreviously the repository was hosted at [Balto](https://helm.baltorepo.com/) and\\nnow it will be hosted at [Buildkite](https://buildkite.com/).\\n\\nUpdate your APT key and references to the repository using the [new installation instructions](https://helm.sh/docs/intro/install/#from-apt-debianubuntu)."},{"id":"helm-at-kubecon-eu-25","metadata":{"permalink":"/blog/helm-at-kubecon-eu-25","editUrl":"https://github.com/helm/helm-www/blob/main/blog/helm-at-kubecon-eu-25.md","source":"@site/blog/helm-at-kubecon-eu-25.md","title":"Helm @ KubeCon + CloudNativeCon EU \'25","description":"It\'s that time of the year again \u2013 the Helm team is headed to KubeCon + CloudNativeCon EU \'25 in London, UK this week from April 1 - 4! Helm 4 is in the works for later this year so be sure to join the conversation with our maintainers during our talk sessions and at our Helm booth in the Project Pavilion! See below for more details on all Helm-related activities throughout the week.","date":"2025-03-31T00:00:00.000Z","tags":[],"readingTime":3.09,"hasTruncateMarker":true,"authors":[{"name":"Karen Chu","page":{"permalink":"/blog/authors/karenchu"},"socials":{"github":"https://github.com/karenhchu","linkedin":"https://www.linkedin.com/in/karenhchu/"},"imageURL":"https://github.com/karenhchu.png","key":"karenchu"}],"frontMatter":{"title":"Helm @ KubeCon + CloudNativeCon EU \'25","slug":"helm-at-kubecon-eu-25","authors":["karenchu"],"date":"2025-03-31"},"unlisted":false,"prevItem":{"title":"Debian/Ubuntu Helm Apt Repository Move","permalink":"/blog/debian-helm-repository-move"},"nextItem":{"title":"Experience a Helm Release: Live at KubeCon + CloudNativeCon North America 2024!","permalink":"/blog/experience-helm-release-kubecon-na-24"}},"content":"It\'s that time of the year again \u2013 the Helm team is headed to KubeCon + CloudNativeCon EU \'25 in London, UK this week from April 1 - 4! Helm 4 is in the works for later this year so be sure to join the conversation with our maintainers during our talk sessions and at our Helm booth in the Project Pavilion! See below for more details on all Helm-related activities throughout the week.\\n\\n\x3c!-- truncate --\x3e\\n\\n## Contribfest: [Expanding the Helm Ecosystem With Helm 4](https://sched.co/1tcyE)\\n\\nDATE: Wednesday April 2\\n\\nTIME: 16:15 - 17:30 BST\\n\\nLOCATION: Level 3 | ICC Capital Suite 17\\n\\nAre you passionate about Helm and looking for ways to contribute? Join Helm maintainers at this ContribFest session to help shape the future of the project and its ecosystem! This session focuses on three exciting initiatives: \\n* Exploring the Helm Ecosystem\\n* Building a Triage Team\\n* Diving into Helm 4\\n\\nDon\'t miss this session with [Scott](https://bsky.app/profile/r6by.bsky.social), [Robert](https://bsky.app/profile/sirchia.cloud), and [Ingy](https://bsky.app/profile/ingydotnet.bsky.social) for your chance at contributing to Helm 4 efforts! For more details on the Contribfest session, check the [session page](https://sched.
1co/1tcyE) for the latest updates. \\n\\n## Helm Maintainer Track Talk: [Helm 4 You](https://sched.co/1td0b)\\n\\nDATE: Thursday April 3\\n\\nTIME: 16:45 - 17:15 BST\\n\\nLOCATION: Level 3 | ICC Capital Suite 10-12\\n\\nJoin Helm maintainers [Matt Farina](https://bsky.app/profile/mattfarina.com) and [Andrew Block](https://bsky.app/profile/andyserver.com) as they provide an update on the next major version of Helm, the timelines, and the features being evaluated. They will also share how the community has been inspirational in helping make Helm 4 a reality. Since Helm continues to be a crucial component in the workflows of users and enterprises worldwide, a new version of Helm is only possible thanks to the continued collaboration from the Cloud Native community.\\n\\nFull details on the talk can be found on the [session page](https://sched.co/1td0b).\\n\\n## Helm Booth in Project Pavilion\\n\\nWED April 2 @ 15:30 \u2013 19:45 BST\\n\\nTHUR April 3 @ 14:00 \u2013 17:00 BST\\n\\nFRI April 4 @ 12:30 \u2013 14:00 BST\\n\\nLOCATION: 2B, near the sticker wall + back side of Backstage\\n\\nOur maintainers and contributors will be staffing the Helm project booth during the second half of each day. Let us know how you\'re using Helm, what questions you have, and learn more about what\'s coming in Helm 4. We\'ll have Helm stickers and *custom Helm tea towels* to help us all remember our time in the UK! \\n\\n## Helm Sessions from the Community\\n\\nAside from sessions with our Helm maintainers, there are several talks from the cloud native ecosystem that touch on Helm \u2013 be sure to check these out as well ~\\n\\n* [Project Lightning Talk: Kubeflow Helm Chart - Krzysztof Romanowski, Maintainer](https://sched.co/1tcvo) // Tuesday April 1, 2025 @ 12:34 - 12:39 BST // Platinum Suite | Level 3\\n* [Project Lightning Talk: Stir to Combine: Creating Porter Mixins - Sarah Christoff, Maintainer](https://sched.co/1tcws) // Tuesday April 1, 2025 @ 16:07 - 16:12 BST // Platinum Suite | Level 3\\n* [Poster Session: Helmless (PS 06): Fast Serverless Deployments Without the Overhead of Kubernetes and Terraform - Michael Reichenbach, 1KOMMA5\xb0](https://sched.co/1txDf) // Wednesday April 2, 2025 @ 13:30 - 14:30 BST // Level 1 | Hall Entrance N8-N9 | Poster Pavilion\\n* [Jaeger V2: OpenTelemetry at the Core of Modern Distributed Tracing - Jonah Kowall, Paessler](https://sched.co/1tcyZ) // Wednesday April 2, 2025 @ 17:00 - 17:30 BST // Level 3 | ICC Capital Suite 10-12\\n* [Into the Shopfloor: Moving Manufacturing Execution Systems To Kubernetes - Manuel Peuster & Andrei Traian Cucuruzac, Bosch Connected Industry](https://sched.co/1txEg) // Friday April 4, 2025 @ 11:45 - 12:15 BST // Level 1 | Hall Entrance N10 | Room E\\n\\nSee everyone this week!"},{"id":"experience-helm-release-kubecon-na-24","metadata":{"permalink":"/blog/experience-helm-release-kubecon-na-24","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2024-11-08-experience-helm-release-kubecon-na-24.md","source":"@site/blog/2024-11-08-experience-helm-release-kubecon-na-24.md","title":"Experience a Helm Release: Live at KubeCon + CloudNativeCon North America 2024!","description":"Have you ever wondered what it takes to perform a software release of one of the most popular tools in the Kubernetes community? While you may envision a series of complex steps or maybe even some black magic (some of which may be true), the release process is much more organized and streamlined than you may have envisioned. However, until you see it for yourself firsthand, these types of questions will continue to go unfulfilled. Seeing it really is believing it!","date":"2024-11-08T00:00:00.000Z","tags":[],"readingTime":1.27,"hasTruncateMarker":true,"authors":[{"name":"Andrew Block","page":{"permalink":"/blog/authors/andrewblock"},"socials":{"github":"https://github.com/sabre1041","linkedin":"https://www.linkedin.com/in/andrewsblock/","website":"https://t.co/utJRRBeHm1"},"imageURL":"https://github.com/sabre1041.png","key":"andrewblock"}],"frontMatter":{"title":"Experience a Helm Release: Live at KubeCon + CloudNativeCon North America 2024!","slug":"experience-helm-release-kubecon-na-24","authors":["andrewblock"],"date":"2024-11-08"},"unlisted":false,"prevItem":{"title":"Helm @ KubeCon + CloudNativeCon EU \'25","permalink":"/blog/helm-at-kubecon-eu-25"},"nextItem":{"title":"Helm at KubeCon/CloudNativeCon SLC","permalink":"/blog/kubecon-slc"}},"content":"Have you ever wondered what it takes to perform a software release of one of the most popular tools in the Kubernetes community? While you may envision a series of complex steps or maybe even some black magic (some of which may be true), the release process is much more organized and streamlined than you may have envisioned. However, until you see it for yourself firsthand, these types of questions will continue to go unfulfilled. Seeing it really is believing it!\x3c!-- truncate --\x3e\\n\\nJoin maintainers and members of the Helm community at KubeCon + CloudNativeCon North America at the Demo Theater during the booth crawl on Wednesday November 13 at 7pm MST as we review the process involved to perform a release of the latest version of Helm so that it can be made available to the entire cloud native community. Along the way, you will learn about the associated activities, individuals, and processes involved with taking source code and transforming it into a consumable artifact for all across a myriad of supported runtimes and platforms.\\n\\nWhether you are a Helm aficionado or just have an interest in release engineering, this is a session that you certainly want to circle on your agendas!\\n\\nNot able to make it to KubeCon + CloudNativeCon North America? Don\u2019t fret! The session will be recorded and made available at a later date.\\n\\nThis release session is just one of several Helm related events taking place at KubeCon + CloudNativeCon North America 2024. A full overview can be found [here](/blog/kubecon-slc)."},{"id":"kubecon-slc","metadata":{"permalink":"/blog/kubecon-slc","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2024-10-07-kubecon-na-24/index.md","source":"@site/blog/2024-10-07-kubecon-na-24/index.md","title":"Helm at KubeCon/CloudNativeCon SLC","description":"KubeCon / CloudNativeCon Logo","date":"2024-11-07T00:00:00.000Z","tags":[],"readingTime":0.92,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm at KubeCon/CloudNativeCon SLC","slug":"kubecon-slc","authors":["mattfarina"],"date":"2024-11-07"},"unlisted":false,"prevItem":{"title":"Experience a Helm Release: Live at KubeCon + CloudNativeCon North America 2024!","permalink":"/blog/experience-helm-release-kubecon-na-24"},"nextItem":{"title":"Helm 2to3 is Now Unsupported","permalink":"/blog/helm2to3-becomes-unsupported"}},"content":"\\n\\nHelm is going to be at KubeCon / CloudNativeCon North America in Salt Lake City. There will be something happening each day of the main conference, including:\x3c!-- truncate --\x3e\\n\\n* Wednesday: \\n * At a booth in the project pavilion from 3:15pm - 8pm.\\n * At 7pm MST we are planning to cut a release, live.\\n* Thursday: \\n * At a project pavilion booth from 1:45pm - 5pm.\\n * Session: [Contribfest: Helm 4: The Next Generation of the Kubernetes Package Manager](https://kccncna2024.sched.com/event/1howt)\\n * Session: [The Path to Helm 4](https://kccncna2024.sched.com/event/1hoxU)\\n* Friday:\\n * 12:30pm - 2:30pm at the project pavilion\\n\\nIf you want to talk with a maintainer to learn about Helm or just give feedback, the project pavilion is the perfect place to do that. If you want to learn about Helm v4 the session \\"The Path to Helm 4\\" is going to give you an overview. If you want to make your first contributions to Helm, the Contribfest session is a place to get started.\\n\\nIf you\'re going to be in Salt Lake City, we hope to see you there."},{"id":"helm2to3-becomes-unsupported","metadata":{"permalink":"/blog/helm2to3-becomes-unsupported","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2024-07-16-helm2to3-becomes-unsupported.md","source":"@site/blog/2024-07-16-helm2to3-becomes-unsupported.md","title":"Helm 2to3 is Now Unsupported","description":"Over four years ago, we introduced Helm 3, a major evolution in Helm\'s development. And we announced at that time that Helm 2 would receive patches and security updates for a year. We also provided a migration path to Helm 3 from Helm 2 and a tool helm-2to3 to automate migration.","date":"2024-0
17-16T00:00:00.000Z","tags":[],"readingTime":1.04,"hasTruncateMarker":true,"authors":[{"name":"Martin Hickey","page":{"permalink":"/blog/authors/martinhickey"},"socials":{"github":"https://github.com/hickeyma","linkedin":"https://www.linkedin.com/in/martin-hickey-b64a374/","website":"https://hickeyma.github.io/"},"imageURL":"https://github.com/hickeyma.png","key":"martinhickey"}],"frontMatter":{"title":"Helm 2to3 is Now Unsupported","slug":"helm2to3-becomes-unsupported","authors":["martinhickey"],"date":"2024-07-16"},"unlisted":false,"prevItem":{"title":"Helm at KubeCon/CloudNativeCon SLC","permalink":"/blog/kubecon-slc"},"nextItem":{"title":"The Road to Helm 4","permalink":"/blog/the-road-to-helm-4"}},"content":"Over four years ago, we [introduced Helm 3](https://helm.sh/blog/helm-3-released/), a major evolution in Helm\'s development. And we [announced](https://helm.sh/blog/2019-10-22-helm-2150-released/) at that time that Helm 2 would receive patches and security updates for a year. We also provided a [migration path to Helm 3 from Helm 2](https://helm.sh/docs/topics/v2_v3_migration/) and a tool [helm-2to3](https://github.com/helm/helm-2to3) to automate migration.\x3c!-- truncate --\x3e\\n\\nOne year later, [Helm 2 became unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/).\\n\\nHere we are, over 3 years since Helm 2 became unsupported. It would be expected that all users should be migrated to Helm 3 by this time. Following consensus among the Helm org maintainers, we are announcing today the official end of support for the [helm-2to3](https://github.com/helm/helm-2to3) tool.\\n\\nIn practice, this means that **Helm 2to3** will receive no more updates (not even security patches).\\n\\nWe strongly discourage the use of the [helm-2to3](https://github.com/helm/helm-2to3) tool moving forward, as it will be receiving no future security updates or patches. We hope that it has been a useful tool to aid in the migration from Helm 2 to 3."},{"id":"the-road-to-helm-4","metadata":{"permalink":"/blog/the-road-to-helm-4","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2024-06-26-the-road-to-helm-4.md","source":"@site/blog/2024-06-26-the-road-to-helm-4.md","title":"The Road to Helm 4","description":"We have been saying it for a while now \u2013 Helm is \\"stable software\\". That should not come as a surprise to anyone familiar with Kubernetes and the surrounding ecosystem as many within the Kubernetes community consider Helm to be the de-facto package manager. The use of Helm is far reaching: from open source community projects, to startups, to Fortune 500 organizations. Helm has become an essential component of build and deployment workflows that handle mission critical workloads.","date":"2024-07-10T00:00:00.000Z","tags":[],"readingTime":5.26,"hasTruncateMarker":true,"authors":[{"name":"Helm Maintainers","page":{"permalink":"/blog/authors/helmmaintainers"},"socials":{"github":"https://github.com/helm","website":"https://helm.sh"},"imageURL":"https://raw.githubusercontent.com/helm/community/refs/heads/main/art/images/Logo-Tweak-Dark.png","key":"helmmaintainers"}],"frontMatter":{"title":"The Road to Helm 4","slug":"the-road-to-helm-4","authors":["helmmaintainers"],"date":"2024-07-10"},"unlisted":false,"prevItem":{"title":"Helm 2to3 is Now Unsupported","permalink":"/blog/helm2to3-becomes-unsupported"},"nextItem":{"title":"Response To CVE-2019-25210","permalink":"/blog/response-CVE-2019-25210"}},"content":"We have been saying it for a while now \u2013 Helm is \\"stable software\\". That should not come as a surprise to anyone familiar with Kubernetes and the surrounding ecosystem as many within the Kubernetes community consider Helm to be the de-facto package manager. The use of Helm is far reaching: from open source community projects, to startups, to Fortune 500 organizations. Helm has become an essential component of build and deployment workflows that handle mission critical workloads.\x3c!-- truncate --\x3e\\n\\nOne of the primary tenets that the Helm project takes very seriously is its policy related to [backwards compatibility](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#semantic-versioning). This strict adherence towards limiting impacts that could adversely affect end consumers is one of the primary reasons why Helm has become such a stable project that the community can count on. Unfortunately, Helm\u2019s backwards compatibility policy does impose limitations to the types of changes or features that can be introduced. It is important to note that Helm is not just a CLI tool, but it is also an SDK. The Helm SDK supports an entire ecosystem of solutions that have been developed to manage Helm content. Any breaking change could negatively impact one of those integrations.\\n\\nHowever, even with strong adherence to the types of changes that the project can make, Helm has been able to introduce new features over time since Helm 3 was released back in 2019. The first such feature, included in Helm 3.1.0, was [post rendering functionality](https://helm.sh/docs/topics/advanced), which allows end users to customize rendered manifests before being installed or upgraded by Helm. Allowing a post rendering step in the Helm release lifecycle was a game changer for both end users and chart maintainers alike. Users no longer have to patch, fork, or manually render chart templates locally to make their custom adjustments. As a result, chart maintainers no longer need to make their charts overly complicated to fit every possible use case under the sun. Since then, minor (new feature) versions of Helm have been released on a quarterly schedule, and continue to bring ever more functionality to end users. Another important new feature introduced during Helm 3 was the support for [OCI registries as a distribution method](https://helm.sh/docs/topics/registries/#using-an-oci-based-registry) for charts. Functionality for this experimental feature shipped with Helm 3.0.0 and became a fully functional feature in 3.8.0. Users of the CLI as well as the SDK could now confidently store charts using the same tried and true method as they store the container images. And, because charts stored in container registries follow OCI standards, Helm users and chart maintainers can use many of the same tools made for container images \u2013 which continue to be improved every day \u2013 to accomplish those tasks with their Helm charts too. Helm helped bring greater standardization to the wider Cloud Native ecosystem as it was one of the first projects that made use of OCI as a
1storage mechanism, which has helped popularize the use of OCI artifacts by other projects. A complete list of new Helm features can be found in the release notes of each minor version [here](https://github.com/helm/helm/releases).\\n\\nThe success of Helm is partially related to the architectural changes that were introduced in Helm 3. Gone are the days of the server side component, Tiller (which limited the use of Helm within multi-tenant), and security conscious environments. Countless other enhancements were also introduced that set Helm version 3 apart from its predecessors.\\n\\nBusinessman Marcus Lemonis said it best: \u201CIf you don\u2019t evolve, you will die\u201D. This sentiment is very much a fact, especially in the technology industry where new tools, approaches, and architectures are introduced with each passing day. It has been 5 years since the release of Helm version 3 and it has become clear, thanks to input from the community, that more impactful changes need to be made to the project so that Helm can continue to serve as an efficient package manager for Kubernetes. That being said, the Helm community is excited to announce the initial kickoff to pave a path toward Helm version 4.\\n\\n## Helm 4 ContribFest at KubeCon EU 2024\\n\\nIt\u2019s often asked: \u201CIs Helm Popular?\u201D. Based on responses from attendees at events, like KubeCon, who fill sessions relating to the project to maximum capacity, the answer continues to remain a resounding \u201CYES\u201D. At the 2024 KubeCon EU in Paris, the first steps towards soliciting feedback from the Open Source community regarding the next version of Helm occurred during the ContribFest in a session titled, \u201CBuilding the Helm 4 Highway\u201D. Clearly, there is an interest in evolving the capabilities that are part of the Helm project. Not only was the session full, but a number of compelling ideas were shared including adding support for additional templating languages other than golang, expanding the use of plugins, and increasing the level of support surrounding the secure software supply chain, such as additional methods of signing charts. The full list of ideas and topics from the ContribFest session can be found [here](https://docs.google.com/document/d/1WJ3K96fJeldKHoKhejWHDvCOTddEvY-RCtQBUaZ57FM/edit#heading=h.2xqu5w422ice).\\n\\n## Getting Involved\\n\\nFor those interested in playing a role in the next version of Helm (we\u2019d love to have you), there are several different ways to participate!\\n\\n1. Join the weekly Helm 4 Roadmap meeting Fridays at 19:00 UTC where members of the community share ideas, develop solutions, and collaborate surrounding the next version of Helm. \\n 1. [Zoom Meeting](https://zoom-lfx.platform.linuxfoundation.org/meeting/91295593969?password=17825db5-c698-44cc-9f00-ef1f61f5d3fb).\\n2. Participate in discussions in the [#helm-dev](https://kubernetes.slack.com/archives/C51E88VDG) channel on the Kubernetes Slack, where members of the Helm community collaborate on Helm development efforts, including those focused on Helm version 4.\\n3. Submit an [issue](https://github.com/helm/helm/issues) within the Helm [GitHub repository](https://github.com/helm/helm).\\n4. Follow [@HelmPack](https://x.com/HelmPack) on Twitter/X for project updates.\\n\\nHelm helped define how to package and manage software for Kubernetes. But let\u2019s not stop there - as we update and develop new features and capabilities in Helm 4, Helm will continue to be a tool that the community can continue to leverage confidently to find, share, and run software on Kubernetes."},{"id":"response-CVE-2019-25210","metadata":{"permalink":"/blog/response-CVE-2019-25210","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2024-03-14-cve-2019-25210.md","source":"@site/blog/2024-03-14-cve-2019-25210.md","title":"Response To CVE-2019-25210","description":"CVE-2019-25210 was recently filed against the Helm project. This action was completed without engaging the Helm project and working through the documented security process and team. The Helm project was given no notice before the disclosure was released which resulted in the inability to provide an appropriate statement beforehand. This post serves as the response from the Helm project.","date":"2024-03-14T00:00:00.000Z","tags":[],"readingTime":3.62,"hasTruncateMarker":true,"authors":[{"name":"Helm Maintainers","page":{"permalink":"/blog/authors/helmmaintainers"},"socials":{"github":"https://github.com/helm","website":"https://helm.sh"},"imageURL":"https://raw.githubusercontent.com/helm/community/refs/heads/main/art/images/Logo-Tweak-Dark.png","key":"helmmaintainers"}],"frontMatter":{"title":"Response To CVE-2019-25210","slug":"response-CVE-2019-25210","authors":["helmmaintainers"],"date":"2024-03-14"},"unlisted":false,"prevItem":{"title":"The Road to Helm 4","permalink":"/blog/the-road-to-helm-4"},"nextItem":{"title":"Helm 3.13","permalink":"/blog/helm-3.13"}},"content":"[CVE-2019-25210](https://nvd.nist.gov/vuln/detail/CVE-2019-25210) was recently filed against the Helm project. This action was completed without engaging the Helm project and working through the [documented security process and team](https://github.com/helm/community/blob/main/SECURITY.md). The Helm project was given no notice before the disclosure was released which resulted in the inability to provide an appropriate statement beforehand. This post serves as the response from the Helm project.\x3c!-- truncate --\x3e\\n\\n## Not A Vulnerability In Helm\\n\\nThe Helm project rejects this disclosure\u2019s assertion of a vulnerability within Helm.\\n\\nThe [advisory listing on GitHub](https://github.com/advisories/GHSA-jw44-4f3j-q396) lists the categorization as [CWE-200](https://cwe.mitre.org/data/definitions/200.html), which is for \u201CExposure of Sensitive Information to an Unauthorized Actor\u201D. The [documentation for this CWE](https://cwe.mitre.org/data/definitions/200.html) notes that its use is discouraged due to frequent misuse. The description aligns with the implementation within Helm in this situation.\\n\\nThe `--dry-run` flag, when used with `helm install` and `helm upgrade`, is designed to send all of the generated chart manifests to standard out that would normally be sent to the Kubernetes API. This is useful for multiple use cases, such as debugging the development of a chart (i.e. package). These manifests are generated from the chart logic. Kubernetes _Secrets_ have been designed by the Kubernetes project to be manifests, like any other resource. When generating manifests, including _Secrets_, there are times they need to be debugged in order to ensure the generated structure is correct.\\n\\nThis functionality, used in many situations including local development environments, is not an issue. The output is not exposed to an unauthorized actor. In fact, the output is needed. If this functionality is used in an environment that captures the output for unauthorized actors, such as in a CI system, then the vulnerability is in the **_use of_** a tool that outputs this information, rather than
1in the tool itself.\\n\\nConsider a simple alternative situation. There is a Kubernetes manifest file containing both secret and non-secret information. `kubectl`, the Kubernetes CLI, is used in an attempt to apply the manifest to a cluster and the attempt fails. So, the `cat` utility is used to display the contents of the file containing the Secret. Is it the vulnerability in `cat` for displaying the information or in the CI setup for using `cat` to display secret information? The vulnerability is in the use of the tool rather than the tool itself.\\n\\n## Helm Changes\\n\\nTo provide greater clarity, the Helm maintainers have made two changes.\\n\\n1. [Documentation has been updated to make the possible exposure of secret information explicit](https://github.com/helm/helm/pull/12859).\\n2. [ A flag has been added](https://github.com/helm/helm/pull/12871), which will be available in the next minor release, that will hide secret information in the dry-run output of these commands.\\n\\n## Why A Delay In Response\\n\\nWhen the CVE listing was released and the Helm maintainers became aware, the team went to work evaluating the potential impacts.\\n\\nThe Helm project takes security seriously. Some examples of this include:\\n\\n* [A documented security policy that enables someone to contact the security team with encrypted communications](https://github.com/helm/community/tree/main/security-audit).\\n* [Two 3rd party security audits (on versions of Helm that contained this functionality)](https://github.com/helm/community/tree/main/security-audit).\\n* [A fuzzing audit and continuous fuzzing has been set up](https://github.com/helm/community/tree/main/security-audit).\\n* [Documented security assurance case](https://github.com/helm/community/tree/main/security-assurance-case), which is an OpenSSF best practices requirement on the way to a silver level.\\n* Helm releases are signed by the maintainer who produced the release.\\n\\nNormally, a discussion about a security issue would stay internal to the Helm project. But, this listing was public and contentious. Helm maintainers contacted security professionals from multiple organizations and sought feedback on the situation prior to publicly commenting or performing any remediation work.\\n\\n## Please Responsibly Contact The Helm Security Team\\n\\nThe Helm security team is responsive. In this calendar year, there have been releases to address two CVEs responsibly reported. You can learn more about reporting security issues in the [documented process](https://github.com/helm/community/blob/main/SECURITY.md) and participate, when necessary, to keep the Helm project and community secure."},{"id":"helm-3.13","metadata":{"permalink":"/blog/helm-3.13","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2023-09-29-helm-3.13.md","source":"@site/blog/2023-09-29-helm-3.13.md","title":"Helm 3.13","description":"Helm 3.13 brings some significant and useful changes for Helm users. This ranges from longtime bugs being fixed to some new features that can have an impact on performance.","date":"2023-09-29T00:00:00.000Z","tags":[],"readingTime":2.69,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm 3.13","slug":"helm-3.13","authors":["mattfarina"],"date":"2023-09-29"},"unlisted":false,"prevItem":{"title":"Response To CVE-2019-25210","permalink":"/blog/response-CVE-2019-25210"},"nextItem":{"title":"The Helm OCI MediaTypes","permalink":"/blog/helm-oci-mediatypes"}},"content":"Helm 3.13 brings some significant and useful changes for Helm users. This ranges from longtime bugs being fixed to some new features that can have an impact on performance.\x3c!-- truncate --\x3e\\n\\n## Dry-run & Template Can Connect To Servers\\n\\nThe dry-run feature on install and upgrade, and Helm template has not been able to communicate with Kubernetes servers. This is for security and because Helm template was designed for template rendering alone.\\n\\nWith Helm 3.13, there is now an opt-in option to communicate with Kubernetes by setting `--dry-run=server`. This tells Helm to communicate with the server for gathering information but not to perform updates. This flag also works on `helm template`. If you use `--dry-run` without setting a value it works as it did before.\\n\\nHelm SDK users will find a new property, named `DryRunOption`, that allows you to tell the SDK to communicate with the server.\\n\\n## Values Handling Improvements\\n\\nValues handling has had a number of bugs filed about it. For example, importing values was inconsistent. Some of the handling even depended on ordering. Using `null` to remove properties was inconsistent, too. It worked in some cases but not others. That\'s fixed in Helm 3.13.\\n\\nThe order you can expect for a value to be used is:\\n\\n1. User specified values (e.g CLI)\\n2. Imported values from dependencies\\
1n3. Parent chart values\\n4. Sub-chart values\\n\\n## JSON Indexes\\n\\nHelm repositories have an index in YAML containing details about the charts and versions of charts it contains. When this file grows large it can be expensive (e.g., processing time and memory) to parse. This is in part because YAML has anchors and aliases which are handy but cause more work to deal with.\\n\\nThose `index.yaml` files can now contain JSON instead of YAML. Helm will generate them when the `--json` flag is set. The `index.yaml` file is used so the same file location can continue to be used for backwards compatibility. The structure for the data is the same. Helm going all the way back to 3.0.0 can handle parsing `index.yaml` files with JSON instead of YAML.\\n\\nTests were run on very large indexes to look at the perform difference. The results found that:\\n\\n- Helm 3 versions before 3.13:\\n - Parsed JSON in ~80% the time of parsing YAML\\n - Used ~93% the memory parsing JSON compared to YAML\\n- Helm 3.13+, with special case handling to detect and handle JSON:\\n - Parsed JSON in ~13% the time of parsing YAML\\n - Used ~5% the memory parsing JSON compared to YAML\\n\\n## Get Metadata Command\\n\\n`helm get` provides the ability to get information about a release in a cluster. It has been able to get values, notes, hooks, and the generated manifests. In addition to those it can now get information about the metadata of the chart the release is based on.\\n\\nTo illustrate this, I installed WordPress and retrieved the metadata:\\n\\n```shell\\n$ helm get metadata wp\\nNAME: wp\\nCHART: wordpress\\nVERSION: 17.1.13\\nAPP_VERSION: 6.3.1\\nNAMESPACE: default\\nREVISION: 1\\nSTATUS: deployed\\nDEPLOYED_AT: 2023-09-28T16:28:30-04:00\\n```\\n\\n## And More...\\n\\nThese are just some of the highlights. Helm 3.13 includes even more features. You can read the details in the [release notes](https://github.com/helm/helm/releases/tag/v3.13.0)."},{"id":"helm-oci-mediatypes","metadata":{"permalink":"/blog/helm-oci-mediatypes","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2023-05-15-helm-oci-mediatypes.md","source":"@site/blog/2023-05-15-helm-oci-mediatypes.md","title":"The Helm OCI MediaTypes","description":"Helm introduced full support for storing charts within OCI registries as a distribution method beginning in version 3.8, and while this feature has been available for some time now, there is more underneath the hood than one may realize to make this capability all possible. A number of concepts, working in unison, make it possible to store content aside from traditional container images within OCI registries. This article will explore one of these important concepts, Media Types, their purpose, and how Helm\u2019s own set of Media Types make it possible to extend the storage of charts beyond standard chart repositories to OCI registries.","date":"2023-05-15T00:00:00.000Z","tags":[],"readingTime":6.05,"hasTruncateMarker":true,"authors":[{"name":"Andrew Block","page":{"permalink":"/blog/authors/andrewblock"},"socials":{"github":"https://github.com/sabre1041","linkedin":"https://www.linkedin.com/in/andrewsblock/","website":"https://t.co/utJRRBeHm1"},"imageURL":"https://github.com/sabre1041.png","key":"andrewblock"}],"frontMatter":{"title":"The Helm OCI MediaTypes","slug":"helm-oci-mediatypes","authors":["andrewblock"],"date":"2023-05-15"},"unlisted":false,"prevItem":{"title":"Helm 3.13","permalink":"/blog/helm-3.13"},"nextItem":{"title":"Helm Completes Fuzzing Security Audit","permalink":"/blog/helm-completes-fuzzing-security-audit"}},"content":"Helm introduced full support for storing charts within OCI registries as a distribution method beginning in version 3.8, and while this feature has been available for some time now, there is more underneath the hood than one may realize to make this capability all possible. A number of concepts, working in unison, make it possible to store content aside from traditional container images within OCI registries. This article will explore one of these important concepts, Media Types, their purpose, and how Helm\u2019s own set of Media Types make it possible to extend the storage of charts beyond standard chart repositories to OCI registries.\x3c!-- truncate --\x3e\\n\\n## OCI Artifacts\\n\\nEven though the majority of content stored within OCI registries are container images, additional content types can also be stored. The [Open Container Initiative (OCI)](https://
1opencontainers.org) defines these other assets as \u201CArtifacts\u201D and the ability to make use of OCI registries to store arbitrary content types has fundamentally changed how content is distributed. Instead of requiring a separate repository management tool for each type of asset, the very same registry that is already present to house container images can be reused without requiring additional software or infrastructure resources. This not only simplifies operational concerns from a hosting perspective, but provides a more uniform method of distributing content.\\n\\nHelm has taken full advantage of the benefits of storing charts as OCI artifacts as it not only eliminates the complexity of managing a traditional chart repository, but simplifies the amount of resources that need to be maintained. When using a chart repository as a distribution and hosting solution, multiple assets need to be maintained:\\n\\n* The packaged chart\\n* An optional provenance file\\n* A repository index file\\n\\nProducing a Helm chart that is stored as an OCI artifact results in an asset with all of the necessary content packaged as a single atomic unit. The structure of the OCI artifact consists of the following three (3) key resources:\\n\\n* An OCI Image Config containing the contents of the Chart.yaml file\\n* The packaged chart within an Image Layer\\n* The provenance file (when included) as an Image Layer\\n\\nThe composition of an OCI Helm Chart and the relationship of each of the aforementioned resources can be seen by inspecting the associated OCI Image Manifest. An example is displayed below:\\n\\n```json\\n{\\n \\"schemaVersion\\": 2,\\n \\"config\\": {\\n \\"mediaType\\": \\"application/vnd.cncf.helm.config.v1+json\\",\\n \\"digest\\": \\"sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111\\",\\n \\"size\\": 117\\n },\\n \\"layers\\": [\\n {\\n \\"mediaType\\": \\"application/vnd.cncf.helm.chart.content.v1.tar+gzip\\",\\n \\"digest\\": \\"sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617\\",\\n \\"size\\": 2487\\n },\\n {\\n \\"mediaType\\": \\"application/vnd.cncf.helm.chart.provenance.v1.prov\\",\\n \\"digest\\": \\"sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a\\",\\n \\"size\\": 643\\n }\\n ]\\n}\\n```\\n\\nThis cross-section illustrates not only the components of an OCI based Helm Chart, but OCI based content in general. Each resource, whether it be a layer or a Config Manifest contain the same sets of properties within the Image Manifest.\\n\\n* Size \u2013 Content size\\n* Digest \u2013 Content addressable reference signifying the algorithm and hash used\\n* Media Type \u2013 Media Type of the referenced content\\n\\nThe Media Type property is arguably the most significant property given the purpose of this discussion. Now that we see where they are referenced within OCI Artifacts, let\u2019s review Media Types in further detail.\\n\\n## Media Types and Their Significance\\n\\nMedia Types, previously known as MIME (Multipurpose Internet Mail Extensions) Types have been around since the early days of the World Wide Web era as they identify file formats and content transmitted through the internet. Their structure consists of two concise sections separated by a slash (/): types and subtypes. Only a limited number of types are defined (10 in total) as they represent a broad use of the type itself. Subtypes are much more diverse and they are organized into a tree structure to enable a hierarchy of related types.\\n\\nA common Media Type that anyone who has experience with RESTful based communication is familiar with is `application/json` as it is used to indicate that the content being transmitted is in JSON format. By indicating a Media Type whenever content is being transferred, the format and its representation is understood by both producers and consumers.\\n\\nThe OCI Image Specification contains several Media Types that represent the various structural elements of an image. These include:\\n\\n* `application/vnd.oci.image.index.v1+json` - Index Image\\n* `application/vnd.oci.image.manifest.v1+json` - Image Manifest\\n* `application/vnd.oci.image.layer.v1.tar+gzip` - gzip compressed Layer\\n\\nThese provide a concrete example to aid in understanding the structural composition of a Media Type. Each of these fall within the `application` type as they are utilized by specific applications. The subtree here can be broken down into the following components:\\n\\n* `vnd` - The vendor tree which are associated with specific products\\n* `oci` - The organization or company responsible\\n* `image` - A short name for the type\\n* `index/manifest/layer` - an optional subcomponent of the type\\n* `v1` - enables the versioning of the schema\\n* `json/tar+gzip` - Optional format signifier \\n\\nA more detailed description of the composition of a Media Type can be found [here](https://github.com/opencontainers/artifacts/blob/main/artifact-authors.md#defining-a-unique-artifact-type).\\n\\n## Helm Media Types\\n\\
1nThe Helm community has worked with the IANA to register three new Media Types representing each of the components comprising an OCI based Helm Chart.\\n\\n* [application/vnd.cncf.helm.config.v1+json](https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.config.v1+json)\\n* [application/vnd.cncf.helm.chart.content.v1.tar+gzip](https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.chart.content.v1.tar+gzip)\\n* [application/vnd.cncf.helm.chart.provenance.v1.prov](https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.chart.provenance.v1.prov)\\n\\nSimilar to the OCI Media Types shown in the prior section, the Helm Media Types are also located within the vendor tree and use the abbreviation for the Cloud Native Computing Foundation (cncf) as the responsible organization. The remainder of the Media Type subtree is fairly self explanatory as it provides additional distinction to the type of content itself and the format. Anyone inspecting a resource within an OCI registry representing a Helm chart would be able to easily identify it as a Helm chart and understand how to interact with the content.\\n\\nFor those interested in learning more about the Helm Media Types, including the low level technical details, can view the registration details within IANA which provides a wealth of information including the intended use and lower level data specification.\\n\\nHelm is certainly not alone in the use of OCI artifacts as a distribution method. Other prominent technologies, including Web Assembly (WASM) and Software Bill of Materials (SBOM\u2019s), also leverage OCI artifacts. It is safe to say that we will see the continued adoption of OCI artifacts as a method of storing content by more and more projects and technologies moving forward.\\n\\n## The Future for Helm\u2019s OCI Media Types\\n\\nAs anyone who has worked in software development, especially with regards to large, complex projects, can relate to the amount of time it takes for features to be implemented. Work surrounding OCI integration was originally introduced back in Helm version 3.5 and how OCI artifacts in general are stored and managed have evolved since that time. The OCI version 1.1 image specification provides not only additional structure, but guidance on how to manage OCI artifacts. As this specification is not only finalized, but adopted and implemented by registry providers, we will continue to see an increased adoption of the technology. The Helm project and community will continue to evolve with the rest of the industry so that Chart producers and consumers have not only the best experience possible, but can best leverage the available technology."},{"id":"helm-completes-fuzzing-security-audit","metadata":{"permalink":"/blog/helm-completes-fuzzing-security-audit","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2023-03-31-helm-completes-fuzzing-security-audit.md","source":"@site/blog/2023-03-31-helm-completes-fuzzing-security-audit.md","title":"Helm Completes Fuzzing Security Audit","description":"In the past year, the team at Ada Logics has worked on integrating continuous fuzzing into the Helm core project. This was an effort focused on improving the security posture of Helm and ensuring a continued good experience for Helm users. The fuzzing integration involved enrolling Helm in the OSS-Fuzz project and writing a set of fuzzers that further enriches the test coverage of Helm. In total, 38 fuzzers were written, and nine bugs were found (with eight fixed so far), demonstrating the work\u2019s value for Helm both short term and long term. All fuzzers were implemented by way of Go-fuzz and are run daily by OSS-Fuzz against the latest Helm commit to make sure Helm is continuously fuzz tested. The full report of the engagement can be found here.","date":"2023-03-31T15:00:00.000Z","tags":[],"readingTime":4.49,"hasTruncateMarker":true,"authors":[{"name":"Adam Korczynski","page":{"permalink":"/blog/authors/adamkorczynski"},"socials":{"github":"https://github.com/AdamKorcz","linkedin":"https://www.linkedin.com/in/adam-korczynski-731909119/"},"imageURL":"https://github.com/AdamKorcz.png","key":"adamkorczynski"},{"name":"David Korczynski","page":{"permalink":"/blog/authors/davidkorczynski"},"socials":{"github":"https://github.com/davidkorczynski","linkedin":"https://www.linkedin.com/in/david-korczynski-875a4957/"},"imageURL":"https://github.com/davidkorczynski.png","key":"davidkorczynski"},{"name":"Martin Hickey","page":{"permalink":"/blog/authors/martinhickey"},"socials":{"github":"https://github.com/hickeyma","linkedin":"https://www.linkedin.com/in/martin-hickey-b64a374/","website":"https://hickeyma.github.io/"},"imageURL":"https://github.com/hickeyma.png","key":"martinhickey"}],"frontMatter":{"title":"Helm Completes Fuzzing Security Audit","slug":"helm-completes-fuzzing-security-audit","authors":["adamkorczynski","davidkorczynski","martinhickey"],"date":"2023-03-31 15:00:00"},"unlisted":false,"prevItem":{"title":"The Helm OCI MediaTypes","permalink":"/blog/helm-oci-mediatypes"},"nextItem":{"title":"Helm welcomes yxxhero as our newest helm-www repo maintainer","permalink":"/blog/welcome-yxxhero"}},"content":"In the past year, the team at [Ada Logics](https://adalogics.com) has worked on integrating continuous fuzzing into the [Helm core project](https://github.com/helm/helm). This was an effort focused on improving the security posture of Helm and ensuring a continued good experience for Helm users. The fuzzing integration involved enrolling Helm in the [OSS-Fuzz project](https://github.com/cncf/cncf-fuzzing) and writing a set of fuzzers that further enriches the test coverage of Helm. In total, 38 fuzzers were written, and nine bugs were found (with eight fixed so far), demonstrating the work\u2019s value for Helm both short term and long term. All fuzzers were implemented by way of [Go-fuzz](https://github.com/dvyukov/go-fuzz) and are run daily by OSS-Fuzz against the latest Helm commit to make sure Helm is continuously fuzz tested. The full report of the engagement can be found [here](https://github.com/helm/community/tree/main/security-audit/FUZZING_AUDIT_2022.pdf).\x3c!-- truncate --\x3e\\n\\n[Helm](https://helm.sh) is described as the Kubernetes package manager. It helps simplify finding, sharing, and using software built for Kubernetes. Helm began as what is now known as [Helm Classic](https://github.com/helm/helm-classic), a Deis project begun in 2015 and introduced at the inaugural KubeCon. In January of 2016, the project merged with a GCS tool called Kubernetes Deployment Manager, and the project was moved under Kubernetes. Helm was promoted from a Kubernetes subproject to a full-fledged CNCF project in June 2018. Helm [graduated as a CNCF project in April 2020](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/). [The CNCF annual survey of 2022](https://www.cncf.io/reports/cncf-annual-survey-2021) found that around 90% of companies are either using or evaluating Kubernetes, and Helm\u2019s performance and security are important, for the continued business operations of these users. \\n\\n## What is fuzzing?\\n\\n[Fuzzing](https://en.wikipedia.org/wiki/Fuzzing) is a technique for testing software for bugs and vulnerabilities by passing it pseudo-random data. The key idea is to write a fuzzing harness similar to a unit \u2014 or integration \u2014 test that will execute the application under test with some arbitrary input. The fuzzing engine that will run the fuzzing harness uses mutational algorithms to generate new input
1s - also called \\"testcases\\" - that will cause the code under test to execute uniquely, i.e., generate inputs that trigger new code execution paths. The goal is then to observe if the code under test misbehaves in the event of any of the generated inputs. Fuzzing has been effective in uncovering reliability bugs and vulnerabilities in software for more than two decades, and open source software is increasingly adopting the technique. \\n\\n## Helm fuzzing overview\\n\\nIn this engagement, the goal was to write a set of fuzzers that would cover a lot of the Helm codebase and integrate the setup into the open source fuzzing service OSS-Fuzz. OSS-Fuzz is a free service offered by Google for critical open source projects to run their fuzzers continuously and report any crashes. Continuous analysis is important due to fuzzing relying on genetic algorithms, which effectively means the fuzzers will improve over time, and OSS-Fuzz will run the fuzzers daily indefinitely. In addition to this, continuous analysis is crucial for capturing any regressions.\\n\\nHelm is written in the Go programming language, making it safe from memory-corruptions. Fuzzing Go will find panics such as slice/index out of range, nil-pointer dereferences, invalid type assertions, timeouts, and out of memory. At the end of this engagement, nine issues were found, all but one of which were fixed. Refer to the report for a detailed breakdown of the issues.\\n\\nAt the end of this engagement, the fuzzers provide significant coverage of the Helm project, including critical parts such as chart handling, release storage, and repositories. To write these fuzzers, Ada Logics used [go-fuzz-headers](https://github.com/AdaLogics/go-fuzz-headers) to deterministically create pseudo-random structs from the data provided by libFuzzer.\\n\\n## Closing thoughts\\n\\nThe Helm team is thankful to CNCF for providing the opportunity to work with Ada Logics to develop new fuzzers for Helm. The CNCF takes security seriously, and it previously funded two third-party security audits for the Helm project, [source code for the Helm client along with the process Helm uses to handle security](https://helm.sh/blog/2019-11-04-helm-security-audit-results/) and [source code for the Helm client along with a threat model for the use of Helm](https://helm.sh/blog/helm-2nd-security-audit/). We want to thank the following Helm maintainers who participated in this endeavour and provided fixes where required: [Matt Butcher](https://github.com/technosophos), [Martin Hickey](https://github.com/hickeyma), [Matt Farina](https://github.com/mattfarina) and [Scott Rigby](https://github.com/scottrigby). We would also like to mention and thank the Flux maintainers, especially [Paulo Gomes](https://github.com/pjbgf) for collaborating on an issue. The fuzzing findings and fixes are valuable add-ons to the previous conclusions of the security audits. The Helm project has efficient test suites, and code changes are backed by tests, but the newly developed fuzzers and findings have provided significant value to the project. During the fuzzing, only nine issues were found, which revalidated the high quality of the Helm code. The Helm team can now maintain the newly developed fuzzers and build on them to continue code quality and security."},{"id":"welcome-yxxhero","metadata":{"permalink":"/blog/welcome-yxxhero","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2022-11-14-welcome-yxxhero.md","source":"@site/blog/2022-11-14-welcome-yxxhero.md","title":"Helm welcomes yxxhero as our newest helm-www repo maintainer","description":"The Helm project is happy to welcome yxxhero as our newest maintainer for the helm-www repo!","date":"2022-11-14T00:00:00.000Z","tags":[],"readingTime":0.36,"hasTruncateMarker":true,"authors":[{"name":"Karen Chu","page":{"permalink":"/blog/authors/karenchu"},"socials":{"github":"https://github.com/karenhchu","linkedin":"https://www.linkedin.com/in/karenhchu/"},"imageURL":"https://github.com/karenhchu.png","key":"karenchu"}],"frontMatter":{"title":"Helm welcomes yxxhero as our newest helm-www repo maintainer","slug":"welcome-yxxhero","authors":["karenchu"],"date":"2022-11-14"},"unlisted":false,"prevItem":{"title":"Helm Completes Fuzzing Security Audit","permalink":"/blog/helm-completes-fuzzing-security-audit"},"nextItem":{"title":"Helm @ KubeCon + CloudNativeCon NA \'22","permalink":"/blog/helm-at-kubecon-na-22"}},"content":"The Helm project is happy to welcome [yxxhero](https://github.com/yxxhero) as our newest maintainer for the helm-www repo! \\n\x3c!-- truncate --\x3e yxxhero has been a long time contributor to the Helm project over the years. With a supermajority vote from the existing maintainers, yxxhero will be joining to help with Helm documentation. With their background, yxxhero will continue to help strengthen both our simplified and traditional Chinese docs.\\n\\nCheers to yxxhero!"},{"id":"helm-at-kubecon-na-22","metadata":{"permalink":"/blog/helm-at-kubecon-na-22","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2022-10-14-helm-at-kubecon-na-22.md","
1source":"@site/blog/2022-10-14-helm-at-kubecon-na-22.md","title":"Helm @ KubeCon + CloudNativeCon NA \'22","description":"The Helm maintainers are excited to be headed to KubeCon + CloudNativeCon NA \'22 in Detroit, MI in a couple of weeks! As always, there will be a few different places you can find us!","date":"2022-10-14T00:00:00.000Z","tags":[],"readingTime":1.38,"hasTruncateMarker":true,"authors":[{"name":"Karen Chu","page":{"permalink":"/blog/authors/karenchu"},"socials":{"github":"https://github.com/karenhchu","linkedin":"https://www.linkedin.com/in/karenhchu/"},"imageURL":"https://github.com/karenhchu.png","key":"karenchu"}],"frontMatter":{"title":"Helm @ KubeCon + CloudNativeCon NA \'22","slug":"helm-at-kubecon-na-22","authors":["karenchu"],"date":"2022-10-14"},"unlisted":false,"prevItem":{"title":"Helm welcomes yxxhero as our newest helm-www repo maintainer","permalink":"/blog/welcome-yxxhero"},"nextItem":{"title":"Tools You Can Use To Manage Your Helm Releases Declaratively","permalink":"/blog/tools-to-manage-helm-declaratively"}},"content":"The Helm maintainers are excited to be headed to KubeCon + CloudNativeCon NA \'22 in Detroit, MI in a couple of weeks! As always, there will be a few different places you can find us!\\n\\n\x3c!-- truncate --\x3e\\n\\n## Helm Maintainer Track Talk: [Learn about Helm and Its Ecosystem](https://sched.co/182Ns)\\n\\nDATE: Thursday October 27\\n\\nTIME: 11:00am - 11:35am EDT\\n\\nLOCATION: Room 410 A\\n\\nMaintainers [Matt Farina](https://twitter.com/mattfarina), [Karena Angell](https://twitter.com/karenaangell), [Scott Rigby](https://twitter.com/r6by), & [Andrew Block](https://twitter.com/sabre1041) will be doing a [Maintainer Track talk](https://sched.co/182Ns) introducing Helm itself and then doing a deep dive into the ecosystem around building packages, along with using Helm packages in clusters. \\n\\n## Helm Booth in Project Pavilion\\n\\nWED OCT 26: 15:30 \u2013 20:00 ET\\n\\nTHUR OCT 27: 14:00 \u2013 17:30 ET\\n\\nFRI Oct 28: 13:00 \u2013 16:00 ET\\n\\nLOCATION: opposite side of the Fuzz booth, near the LitmusChaos/Flux/Cortex/Falco booths\\n\\nOur maintainers will be hanging out at our Helm project booth the second half of each day. We\'d love to learn from the community how Helm is being used, what pain points exists, and what users are looking for in the future. Help us help you by sharing your thoughts in our [Helm User Survey](https://docs.google.com/forms/d/e/1FAIpQLSeR9fSlWShh49_URhAEPA88JVjlPiz1441CA1B2ySJGZg1dzQ/viewform), even if you\'re unable to drop by the booth. \\n\\nNow for the fun part \u2013 the Helm booth will be giving away 3D Helm stickers, glow-in-the-dark Helm stickers, Helm bike bells, or limited edition Helm + Carhartt beanies to stay warm while in Detroit!\\n\\nWith that, we\'ll see the Helm community soon in-person!"},{"id":"tools-to-manage-helm-declaratively","metadata":{"permalink":"/blog/tools-to-manage-helm-declaratively","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2022-04-19-tools-to-manage-helm-declaratively.md","source":"@site/blog/2022-04-19-tools-to-manage-helm-declaratively.md","title":"Tools You Can Use To Manage Your Helm Releases Declaratively","description":"We regularly get questions from people who want tools or methods to manage their Helm releases in an environment. This post provides some insight and direction to help people get started.","date":"2022-04-19T00:00:00.000Z","tags":[],"readingTime":6.24,"hasTruncateMarker":true,"authors":[{"name":"Scott Rigby","page":{"permalink":"/blog/authors/scottrigby"},"socials":{"github":"https://github.com/scottrigby","linkedin":"https://www.linkedin.com/in/scottrigby/","website":"http://basekamp.com/"},"imageURL":"https://github.com/scottrigby.png","key":"scottrigby"},{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Tools You Can Use To Manage Your Helm Releases Declaratively","slug":"tools-to-manage-helm-declaratively","authors":["scottrigby","mattfarina"],"date":"2022-04-19"},"unlisted":false,"prevItem":{"title":"Helm @ KubeCon + CloudNativeCon NA \'22","permalink":"/blog/helm-at-kubecon-na-22"},"nextItem":{"title":"Storing Helm Charts in OCI Registries","permalink":"/blog/storing-charts-in-oci"}},"content":"We regularly get questions from people who want tools or methods to manage their Helm releases in an environment. This post provides some insight and direction to help people get started.\\n\\n\x3c!-- truncate --\x3e\\n\\n## Why Helm Doesn\'t Have Tools To Do This\\n\\nYou might wonder, why doesn\'t Helm provide tools to do this out of the box?\\n\\nHelm is a package manager. We often compare it to package managers for other platforms like apt, yum, zipper, homebrew, and others. All of these projects, Helm included, keep their scope within the realm of package management.\\n\\nManaging how instances of packages are run in an environment is a separate concern and one people have varying ideas about. For example, some people use Ansible, others use Terraform, some use both, and some use something entirely different. Different tools can even use different methods (e.g. some are push based and others pull based). _All of these are able work with the same package managers._\\n\\nThe Helm project strives to provide a package manager that works well with various other tools that can use a variety of different methods to manage releases.\\n\\n## Declarative and Imperative\\n\\nIn the Kubernetes space we talk about _declarative_ management. If you\'re not familiar with the concept, here is a brief explanation.\\n\\nWith declarative management you _declare_ to the _system_ what you want the end state to look like. For example, that you want X number of instances of your workload to be running. The system then works to make this a reality and usually reports status on the progress of making the declared status a reality. Over time, the way the system makes the declared state a reality can change without the need for what you declare or the status of the progress to change.\\n\\nImperative management has to do with telling the system what to do step by step. Instead of declaring what you want you tell the system each step to take to achieve the end goal.\\n\\nKubernetes provides a means to do both [declarative and imperative management of resources](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/). As the Kubernetes community tends to prefer declarative management, when possible, the rest of this post is going to focus on declarative tools you can use with Helm.\\n\\n## Tools\\n\\
1nThe Kubernetes ecosystem has produced numerous projects of various styles to help you declaratively manage your Helm releases. To illustrate the options we will look at sister projects to Helm in the Cloud Native Computing Foundation (CNCF) and some more general open source projects. You can find more options in the [CNCF Landscape](https://landscape.cncf.io/).\\n\\n### CNCF Projects\\n\\nThe scope of this section is limited to [graduated and incubating](https://www.cncf.io/projects/) CNCF projects. There are over 100 CNCF projects and many of them are [sandbox projects](https://www.cncf.io/sandbox-projects/). You can learn more about the differences between types of projects in the [maturity level explanation](https://www.cncf.io/projects/#maturity-levels). The following projects are worth looking at:\\n\\n* [Flux Helm Controller](https://fluxcd.io/docs/components/helm/) - [Flux](https://fluxcd.io/) is a collection of projects that enable GitOps. One of the components provides a GitOps method to manage Helm releases. Flux natively supports Helm.\\n* [Argo CD](https://github.com/argoproj/argo-cd) - The [Argo](https://argoproj.github.io/) project defines itself as providing \\"Open source tools for Kubernetes to run workflows, manage clusters, and do GitOps right.\\" Argo CD is focused on declarative continuous delivery and has the ability to work with Helm charts.\\n\\n### Other Projects\\n\\nThere are many projects beyond the CNCF projects you can use to help you manage your Helm releases. The following set is an example and not exhaustive.\\n\\n* [Helmfile](https://github.com/helmfile/helmfile) - A declarative spec for deploying Helm charts.\\n* [Captain](https://github.com/alauda/captain) - A Helm controller.\\n* [Terraform Helm provider](https://github.com/hashicorp/terraform-provider-helm) - Enables you to manage Helm charts through Terraform.\\n* [Orkestra](https://azure.github.io/orkestra/) - Built on other tools in this list, Orkestra adds a robust dependency graph for a related group of Helm releases and their subcharts, as well as a reverse DAG for specifying dependency requirements for rollbacks.\\n* [Fleet](https://github.com/rancher/fleet) - A GitOps tool chain that works with Kubernetes manifests, Helm charts, and Kustomize.\\n\\n### High-Level Tool Comparison\\n\\nThere are some differences between the tools we\'ve looked at so far. The following table provides some insight into their differences. This is not exhaustive and you should evaluate any tools you use yourself.\\n\\n| | Retains Helm release info | Supports Helm hooks | OCI support | Does not require Helm binary |\\n| -- | -- | -- | -- | -- |\\n| Flux Helm controller | \u2705 | \u2705 | \u{1F6AB}[^1] | \u2705 |\\n| Argo CD | \u{1F6AB} | :warning:[^2] | \u2705[^3] | \u{1F6AB} |\\n| Helmfile | \u2705 | :warning:[^4] | :warning:[^5] | \u{1F6AB}[^6] |\\n| Captain | \u2705 | \u2705 | :warning:[^7] | \u2705 |\\n| Terraform Helm provider | \u2705 | :warning:[^8] | \u2705 | \u2705 |\\n| Orkestra | \u2705 | \u2705 | \u{1F6AB}[^9] | \u2705 |\\n| Fleet | \u2705 | \u2705 | \u{1F6AB}[^10] | \u2705 |\\n\\n_Note, this comparison is from when the blog post was published. Projects change over time and the feature set may change over time. You should evaluate the projects in their current state before choosing one._\\n\\n## Conclusion\\n\\nIf you want to use a configuration manager with your Helm and Kubernetes configuration there are many choices. While the Helm project doesn\'t endorse one project over another, we do suggest using a configuration manager when it\'s appropriate.\\n\\n[^1]: Because Flux makes full use of the Helm SDK, as of Helm v3.8.0 Flux is now unblocked to add OCI artifact integration (Flux team members helped finish bringing OCI support out of experimental into a full feature in Helm). [RFC-0002](https://github.com/fluxcd/flux2/tree/main/rfcs/0002-helm-oci) is now marked as implementable, and work on this is now in progress for Flux. You can follow this fluxcd/source-controller issue [#669](https://github.com/fluxcd/source-controller/issues/669) for progress.\\n[^2]: Because Argo does not retain Helm release information, there is an [attempt to map](https://argo-cd.readthedocs.io/en/stable/user-guide/helm/#helm-hooks) Helm hooks to ArgoCD hooks, however, there are far fewer Argo hooks and unmappable concepts such as no differentiation between install and upgrade. You can work around this by writing your charts specifically for ArgoCD, however hooks in commonly used community charts will not work.\\n[^3]: ArgoCD shells out to the Helm CLI, only to render templates. This has allowed Argo to turn on Helm CLI\'s OCI feature before it was finished, for the same reason that it can not support Helm features beyond templating. Because of this, OCI is not part of the ArgoCD source architecture.\\n[^4]: Helmfile has a custom concept of hooks, not necessarily mapped to Helm hooks. See readme [hooks section](https://github.com/helmfile/helmfile#hooks) and [this issue](https://github.com/roboll/helmfile/issues/1291) for clarification and work in progress.\\n[^5]: Helmfile has experimental OCI support, without explicitly explaining to users that it sets `HELM_EXPERIMENTAL_OCI=1` before shelling out to the Helm CLI. See [#2112](https://github.com/roboll/helmfile/issues/2112) and [#2111](https://github.com/roboll/helmfile/issues/2111).\\n[^6]: Helmfile parameterizes the Helm binary (default: `helm`).\\n[^7]: Captain relies on a related project [alauda/oci-chartrepo](https://github.com/alauda/oci-chartrepo) to mix concepts of using oci registry as helm chart repo.\\n[^8]: Terraform Helm provider has [some issues](https://github.com/hashicorp/terraform-provider-helm/issues/683) with Helm hooks and wait configurations.\\n[^9]: Orkestra leverages Flux Helm Controller to reconcile the releases. See the note above about Flux Helm controller OCI status. Once a full implementation is released in Flux, Orkestra will also support OCI.\\n[^10]: Fleet uses the Helm SDK. Once it uses a version of the Helm SDK that supports OCI registries, Fleet will inherit support."},{"id":"storing-charts-in-oci","metadata":{"permalink":"/blog/storing-charts-in-oci","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2022-02-28-storing-charts-in-oci.md","source":"@site/blog/2022-02-28-storing-charts-in-oci.md","title":"Storing Helm Charts in OCI Registries","description":"With the release of Helm 3.8.0, Helm is able to store and work with charts in container registries, as an alternative to Helm repositories. This feature, which used to be an experimental feature, is now generally available.","date":"2022-02-28T00:00:00.000Z","tags":[],"readingTime":3.74,"hasTruncateMarker":true,"authors":[{"name":"Scott Rigby","page":{"permalink":"/blog/authors/scottrigby"},"socials":{"github":"https://github.com/scottrigby","linkedin":"https://www.linkedin.com/in/scottrigby/","website":"http://basekamp.com/"},"imageURL":"https://github.com/scottrigby.png","key":"scottrigby"},{"name":"Josh Dolitsky","page":{"permalink":"/blog/authors/joshdolitsky"},"socials":{"github":"https://github.com/jdolitsky","linkedin":"https://www.linkedin.com/in/jdolitsky/"},"imageURL":"https://github.com/jdolitsky.png","key":"joshdolitsky"},{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Storing Helm Charts in OCI Registries","slug":"storing-charts-in-oci","authors":["scottrigby","joshdolitsky","mattfarina"],"date":"2022-02-28"},"unlisted":false,"prevItem":{"title":"Tools You Can Use To Manage Your Helm Releases Declaratively","permalink":"/blog/tools-to-manage-helm-declaratively"},"nextItem":{"title":"Karen Chu Joins Helm Org Maintainers","permalink":"/blog/welcome-karen-chu"}},"content":"With the release of Helm 3.8.0, Helm is able to store and work with charts in container registries, as an alternative to [Helm repositories](https://helm.sh/docs/topics/chart_repository/). This feature, which used to be an experimental feature, is now generally available.\\n\\n\x3c!-- truncate --\x3e\\n\\nOver the past several years container registry developers have been working on ways to store other artifacts in container registries. To facilitate this in a cross platform manner, the Open Containers Initiative (OCI) - the organization that defines the specifications for c
1ontainers - released their [distribution specification](https://specs.opencontainers.org/distribution-spec/?v=v1.0.0) which allowed other \\"artifacts\\" to be stored in registries.\\n\\n\x3c!-- ## What Does This Mean For Me? --\x3e\\n\\n## Common Storage\\n\\nSince OCI artifacts now makes it possible to store more than container images, you can store charts, images, and other artifacts in a single OCI registry. Sharing a common storage standard that\'s not specific to Helm allows greater interoperability between tools from the wider container ecosystem for security, identity and access management, and more.\\n\\n## Working With Charts In Registries\\n\\nThe combination of OCI artifact support in a registry and new functionality within Helm provides the capability to pull and push charts to and from a registry. You can also specify charts stored in OCI as a dependency in any `Chart.yaml` file. The following example illustrates logging into a registry and pushing a chart:\\n\\n```text\\n$ helm create demo\\nCreating demo\\n\\n$ helm package demo\\nSuccessfully packaged chart and saved it to: /tmp/demo-0.1.0.tgz\\n\\n$ echo \\"mypass\\" | helm registry login r.example.com -u myuser --password-stdin\\nLogin Succeeded\\n\\n$ helm push demo-0.1.0.tgz oci://r.example.com/myuser\\nPushed: r.example.com/myuser/demo:0.1.0\\nDigest: sha256:7ed393daf1ffc94803c08ffcbecb798fa58e786bebffbab02da5458f68d0ecb0\\n```\\n\\nMore detail on [working with registries can be found in the Helm documentation](https://helm.sh/docs/topics/registries/).\\n\\n## The Helm SDK\\n\\nThe Helm SDK, which is useful for those building tools to integrate with Helm, also includes support to work with registries programmatically. The following example illustrates pushing a chart to a registry:\\n\\n```go\\npackage main\\n\\nimport (\\n\\t\\"fmt\\"\\n\\t\\"io/ioutil\\"\\n\\n\\t\\"helm.sh/helm/v3/pkg/registry\\"\\n)\\n\\nfunc check(err error) {\\n\\tif err != nil {\\n\\t\\tpanic(err)\\n\\t}\\n}\\n\\nfunc main() {\\n\\tclient, err := registry.NewClient()\\n\\tcheck(err)\\n\\n\\tb, err := ioutil.ReadFile(\\"demo-0.1.0.tgz\\")\\n\\tcheck(err)\\n\\n\\tinfo, err := client.Push(b, \\"r.example.com/myuser/demo:0.1.0\\")\\n\\tcheck(err)\\n\\n\\tfmt.Printf(\\"Pushed: %s\\\\n\\", info.Ref)\\n\\tfmt.Printf(\\"Digest: %s\\\\n\\", info.Manifest.Digest)\\n}\\n```\\n\\nMore detail can be found in the [documentation for the registry package](https://pkg.go.dev/helm.sh/helm/v3/pkg/registry).\\n\\n## Limitations\\n\\nThere are some limitations when using registries to store charts compared to Helm repositories or storing container images in registries.\\n\\nHelm repositores can be added and searched from the local Helm client. This is similar to how repositories work with other package managers such as zypper or apt. When working with OCI registries, this is not an option. OCI based registries don\'t provide standard APIs to facilitate searching.\\n\\nWhile the OCI specification provides support for artifacts, not all registries support storing Helm charts or other artifacts that are not container images. Before choosing a registry, you should confirm whether it supports storing Helm charts.\\n\\n## Artifact Hub Support\\n\\n[Artifact Hub](https://artifacthub.io/), another CNCF project, provides a means to search and discover cloud native assets, including charts. Helm charts stored in OCI based registries can be listed on Artifact Hub, which already knows how to work with them. More details on working with Artifact Hub and Helm charts in container registries can be found in their [documentation](https://artifacthub.io/docs/topics/repositories/#helm-charts-repositories).\\n\\n## ORAS\\n\\nThe [OCI Registry as Storage (ORAS) project](https://oras.land/), another CNCF project, is used by Helm as the underlying library for working with registries. The ORAS project bills itself as:\\n\\n> Registries are evolving as generic artifact stores. To enable this goal, the ORAS project provides a way to push and pull OCI Artifacts to and from OCI Registries.\\n\\nIf you want to work with other artifacts in registries the ORAS project may provide some tools to help you.\\n\\n## Thanks and Help Us Keep Improving\\n\\nThanks to everyone who worked on adding support for Helm charts and OCI registries, from the initial experiment to bringing this to a full feature. Thanks especially for end user testing, bug reports and feature requests, and coordination between community members and maintainers across several CNCF projects.\\n\\nWe hope this post helps give a good intro, and some things to consider when evaluating storing your Helm charts in OCI. See if it fits your needs, take it for a spin, and let us know what you think!"},{"id":"welcome-karen-chu","metadata":{"permalink":"/blog/welcome-karen-chu","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2022-01-11-welcome-karen-chu.md","
1source":"@site/blog/2022-01-11-welcome-karen-chu.md","title":"Karen Chu Joins Helm Org Maintainers","description":"The Helm organization is thrilled to introduce Karen Chu as the latest member of the Helm org maintainers. She will be the ninth committee member. Karen has been active in the Helm ecosystem since day one when Rimas, Jack, and I first started the project. She was instrumental in Helm\'s early branding, organized both of the Helm Summits, and leads Helm\'s community management team. You may also know her from her Helm-adjacent work as the co-creator of the Illustrated Children\'s Guide to Kubernetes series or her role as a CNCF ambassador.","date":"2022-01-11T00:00:00.000Z","tags":[],"readingTime":0.84,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"}],"frontMatter":{"title":"Karen Chu Joins Helm Org Maintainers","slug":"welcome-karen-chu","authors":["mattbutcher"],"date":"2022-01-11"},"unlisted":false,"prevItem":{"title":"Storing Helm Charts in OCI Registries","permalink":"/blog/storing-charts-in-oci"},"nextItem":{"title":"Martin Hickey Joins Helm Org Maintainers","permalink":"/blog/welcome-martin-hickey"}},"content":"The Helm organization is thrilled to introduce [Karen Chu](https://twitter.com/karenhchu) as the latest member of the [Helm org maintainers](https://github.com/helm/community/blob/main/governance/governance.md#helm-org-maintainers). She will be the [ninth committee member](https://github.com/helm/community/blob/main/MAINTAINERS.md). Karen has been active in the Helm ecosystem since day one when Rimas, Jack, and I first started the project. She was instrumental in Helm\'s early branding, organized both of the Helm Summits, and leads Helm\'s community management team. You may also know her from her Helm-adjacent work as the co-creator of the [Illustrated Children\'s Guide to Kubernetes](https://www.cncf.io/phippy/) series or her role as a CNCF ambassador.\x3c!-- truncate --\x3e\\n\\nLast week, the Helm project maintainers voted to elect Karen onto the Helm org maintainers board. In this role, Karen will help shape the many projects that are hosted under the Helm umbrella, bringing her insights from the wider ecosystem to her leadership of the Helm organization.\\n\\nCongratulations to Karen!"},{"id":"welcome-martin-hickey","metadata":{"permalink":"/blog/welcome-martin-hickey","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2021-06-24-welcome-martin-hickey.md","source":"@site/blog/2021-06-24-welcome-martin-hickey.md","title":"Martin Hickey Joins Helm Org Maintainers","description":"Meet Helm\'s newest org maintainer: Martin Hickey. Martin has been a longtime Helm project maintainer. He was instrumental in the development of Helm 3, and has been one of the most active maintainers on the project. He is also one of the creators of the Helm 2-to-3 migration plugin.","date":"2021-06-24T00:00:00.000Z","tags":[],"readingTime":0.61,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"}],"frontMatter":{"title":"Martin Hickey Joins Helm Org Maintainers","slug":"welcome-martin-hickey","authors":["mattbutcher"],"date":"2021-06-24"},"unlisted":false,"prevItem":{"title":"Karen Chu Joins Helm Org Maintainers","permalink":"/blog/welcome-karen-chu"},"nextItem":{"title":"Helm 2nd Security Audit","permalink":"/blog/helm-2nd-security-audit"}},"content":"Meet Helm\'s newest org maintainer: [Martin Hickey](https://hickeyma.github.io/). Martin has been a longtime Helm project maintainer. He was instrumental in the development of Helm 3, and has been one of the most active maintainers on the project. He is also one of the creators of the [Helm 2-to-3 migration plugin](https://github.com/helm/helm-2to3).\x3c!-- truncate --\x3e\\n\\nThis week, the Helm maintainers voted to elect Martin onto the Helm Org Maintainers board. In this new role, Martin will help shape not just Helm, but the many projects that are hosted together with Helm. As a first order of business, Martin will be migrating the [Map KubeAPIs plugin](https://github.com/hickeyma/helm-mapkubeapis) to the Helm organization.\\n\\nCongratulations to Martin!"},{"id":"helm-2nd-security-audit","metadata":{"permalink":"/blog/helm-2nd-security-audit","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2021-03-05-second-security-audit/index.md","source":"@site/blog/2021-03-05-second-security-audit/index.md","title":"Helm 2nd Security Audit","description":"Helm has now completed a second security audit, funded by the CNCF. The first audit focused on the source code for the Helm client along with the process Helm uses to handle security. The second audit, performed by Trail of Bits, looked at the source code for the Helm client along with a threat model for the use of Helm.","date":"2021-03-05T00:00:00.000Z","tags":[],"readingTime":1.2,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm 2nd Security Audit","slug":"helm-2nd-security-audit","authors":["mattfarina"],"date":"2021-03-05"},"unlisted":false,"prevItem":{"title":"Martin Hickey Joins Helm Org Maintainers","permalink":"/blog/welcome-martin-hickey"},"nextItem":{"title":"Helm 2 and the Charts Project Are Now Unsupported","permalink":"/blog/helm-2-becomes-unsupported"}},"content":"Helm has now completed a second security audit, funded by the [CNCF](https://cncf.io). The [first audit](https://helm.sh/blog/2019-11-04-helm-security-audit-results/) focused on the source code for the Helm client along with the process Helm uses to handle security. The second audit, performed by [Trail of Bits](https://www.trailofbits.com/), looked at the source code for the Helm client along with a threat model for the use of Helm.\x3c!-- truncate --\x3e\\n\\nThe following diagram is from the [threat model](https://github.com/helm/community/blob/main/security-audit/Helm%20Threat%2
10Model%202020.pdf) and looks at the connections Helm makes along with how it stores files on the local filesystem.\\n\\n\\n\\nAs a result of the audit, the Helm security team worked on [a release](https://github.com/helm/helm/releases/tag/v3.3.2).\\n\\nWe want to thank the CNCF for providing these security assessments. They provide an expert and outside look at projects, like Helm, so that we can have more security cloud native tooling. We also want to thank Trail of Bits for the assessment. It was a pleasure working with them.\\n\\nYou can get the full reports for the [threat model](https://github.com/helm/community/blob/main/security-audit/Helm%20Threat%20Model%202020.pdf) and [security assessment](https://github.com/helm/community/blob/main/security-audit/Helm%20Final%20Report%202020.pdf) in the [Helm community repository](https://github.com/helm/community/tree/main/security-audit)."},{"id":"helm-2-becomes-unsupported","metadata":{"permalink":"/blog/helm-2-becomes-unsupported","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-11-13-helm-2-becomes-unsupported.md","source":"@site/blog/2020-11-13-helm-2-becomes-unsupported.md","title":"Helm 2 and the Charts Project Are Now Unsupported","description":"A year ago, we introduced Helm 3, a major evolution in Helm\'s development. And we announced at that time that Helm 2 would receive patches and security updates for a year.","date":"2020-11-13T00:00:00.000Z","tags":[],"readingTime":1.53,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"}],"frontMatter":{"title":"Helm 2 and the Charts Project Are Now Unsupported","slug":"helm-2-becomes-unsupported","authors":["mattbutcher"],"date":"2020-11-13"},"unlisted":false,"prevItem":{"title":"Helm 2nd Security Audit","permalink":"/blog/helm-2nd-security-audit"},"nextItem":{"title":"Helm\u2019s First Patch Wednesday","permalink":"/blog/helm-release-process"}},"content":"A year ago, we [introduced Helm 3](https://helm.sh/blog/helm-3-released/), a major evolution in Helm\'s development. And we [announced](https://helm.sh/blog/2019-10-22-helm-2150-released/) at that time that Helm 2 would receive patches and security updates for a year.\\n\\nHere we are, one year later. Friday the 13th, 2020 seems like a fitting day to end support for a major version. And today, we are announcing the official end of support for Helm 2. The charts repository is also now read-only, with no further changes.\x3c!-- truncate --\x3e\\n\\nFrom this point forward, the Helm team will devote all of its energy to Helm 3 and our ecosystem tools.\\n\\nIn practice, this means the following:\\n\\n- **Helm 2** will receive no more updates (not even security patches).\\n- The **Helm Charts** [GitHub project](https://github.com/helm/charts) will receive no more updates.\\n- The Helm **Stable and Incubator charts** repositories have been moved to an archive. See [our blog post](https://helm.sh/blog/new-location-stable-incubator-charts/) for more.\\n- **Helm 3** will [continue](https://github.com/helm/helm/releases) to add new features, fix bugs, and address security issues.\\n- [Other Helm projects](https://github.com/helm) like our **GitHub actions** will continue feature development as well.\\n- **Artifact Hub** is now the official location for [finding Helm charts](https://artifacthub.io/).\\n\\nWe strongly discourage continued use of Helm 2, as it will be receiving no future security updates or patches. But if you need more time to migrate, we strongly encourage you to upgrade to Helm [2.17.0](https://github.com/helm/helm/releases/tag/v2.17.0), which has the final patches. For more, [check out the migration documentation](https://helm.sh/docs/topics/v2_v3_migration/).\\n\\nFinally, I would like to close with a heartfelt word of thanks to the dedicated people who have contributed to Helm and Charts over the years."},{"id":"helm-release-process","metadata":{"permalink":"/blog/helm-release-process","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-11-11-helm-release-process.md","source":"@site/blog/2020-11-11-helm-release-process.md","title":"Helm\u2019s First Patch Wednesday","description":"Helm recently adopted a release schedule for minor and patch releases. Today, the second Wednesday in November 2020, marks the first release under the new schedule. This release schedule provides predictability to those who use Helm, contribute to Helm, and maintain Helm.","date":"2020-11-11T00:00:00.000Z","tags":[],"readingTime":1.16,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm\u2019s First Patch Wednesday","slug":"helm-release-process","authors":["mattfarina"],"date":"2020-11-11"},"unlisted":false,"prevItem":{"title":"Helm 2 and the Charts Project Are Now Unsupported","permalink":"/blog/helm-2-becomes-unsupported"},"nextItem":{"title":"Helm Chart Repository Deprecation Update","permalink":"/blog/charts-repo-deprecation"}},"content":"Helm recently adopted [a release schedule for minor and patch releases](https://github.com/helm/community/blob/main/hips/hip-0002.md). Today, the second Wednesday in November 2020, marks the first release under the new schedule. This release schedule provides predictability to those who use Helm, contribute to Helm, and maintain Helm.\x3c!-- truncate --\x3e\\n\\nThe release schedule generally follows these rules:\\n\\n* Patch releases happen on the 2nd Wednesday of the month when there isn\'t a major or minor release. This will happen if there are changes that could be released.\\n* Minor releases will roughly align with Kubernetes releases and have three to four month development windows, as Kubernetes does. These releases will lag behind Kubernetes so that Helm can be updated and tested for any changes to Kubernetes.\\n* When a minor version is released the next minor version will be scheduled. The date will be published to https://helm.sh/. For example, v3.5.0 is scheduled for Wednesday January 13th. Instead of a patch release that day there will be a minor release.\\n* Security releases do not need to follow any of these rules. They will be released as needed.\\n\\nA calendar of upcoming dates for releases can be found on the calendar at https://helm.sh/calendar/release. This is a redirect to the calendar.\\n\\nMore details can be found in [Helm Improvement Proposal 2](https://github.com/helm/community/blob/main/hips/hip-0002.md)."},{"id":"charts-repo-deprecation","metadata":{"permalink":"/blog/charts-repo-deprecation","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-10-30-charts-repo-deprecation.md","source":"@site/blog/2020-10-30-charts-repo-deprecation.md","title":"Helm Chart Repository Deprecation Update","description":"Back in 2019, when the Helm v2 support timeline and end of life plan was announced, the deprecation of the helm/charts GitHub repository was announced, as well. The primary reason for the deprecation is the significant increase in upkeep for the repo maintainers. Over the last couple of years the number of charts under maintenance increased from ~100 to 300+ causing a commensurate increase in pull requests and updates to the repo. Unfortunately, despite many efforts to automate review and maintenance tasks, the amount of time available from maintainers has not increased.","date":"2020-10-30T00:00:00.000Z","tags":[],"readingTime":2.58,"hasTruncateMarker":true,"authors":[{"name":"Vic Iglesias","page":{"permalink":"/blog/authors/viciglesias"},"socials":{"github":"https://github.com/viglesiasce","linkedin":"https://www.linkedin.com/in/viglesias/"},"imageURL":"https://github.com/viglesiasce.png","key":"viciglesias"}],"frontMatter":{"title":"Helm Chart Repository Deprecation Update","slug":"charts-repo-deprecation","authors":["viciglesias"],"date":"2020-10-30"},"unlisted":false,"prevItem":{"title":"Helm\u2019s First Patch Wednesday","permalink":"/blog/helm-release-process"},"nextItem":{"title":"New Location For Stable and Incubator Charts","permalink":"/blog/new-location-stable-incubator-charts"}},"content":"Back in 2019, when the Helm v2 support timeline and end of life plan was announced, [the deprecation](https://github.com/helm/charts#deprecation-timeline) of the [helm/charts GitHub repository](https://github.com/helm/charts) was announced, as well. The primary reason for the deprecation is the significant increase in upkeep for the [repo maintainers](https://github.com/helm/charts/blob/master/OWNERS). Over the last couple of years the number of charts under maintenance increased from ~100 to 300+ causing a commensurate increase in pull requests and updates to the repo. Unfortunately, despite many efforts to automate review and maintenance tasks, the amount of time available from maintainers has not increased.\x3c!-- truncate --\x3e\\n\\nWhen we announced the deprecation we also began to share the tools and guidance that we had used to maintain the helm/charts repo. For folks that want to host and maintain their own repositories you now have these tools available to streamline the process:\\n\\n- [Chart Testing](https://github.com/helm/chart-testing) provides linting and testing for PRs against your charts\\n- [Chart Releaser](https://github.com/helm/chart-releaser) provides tooling to help you host your own chart repo with GitHub Releases and Pages used to host your artifacts\\n- [Testing and Releasing Github Actions](https://github.com/helm?q=chart+action) to automate the tooling described above using GitHub Actions\\n\\nWith these tools available we\'ve enabled many charts to [migrate to their own repositories](https://github.com/helm/charts/issues/21103) for active maintenance.\\n\\n## Key Dates and Recommended Actions\\n\\nThere has been refinement to the plans and confusion/questions about what happens next, so we wanted to provide a timeline of key events and **recommended actions** moving forward:\\n\\n* Nov 2, 2020 - READMEs for all non-deprecated charts will get a note added, stating that they will no longer be updated\\n * **RECOMMENDED ACTION**
1- If you depend on a chart in the Charts repository look for the new official location. If one does not exist, consider adopting the chart.\\n* Nov 6, 2020 the stable and incubator charts repos will be removed from the [Artifact Hub](https://artifacthub.io/)\\n * **RECOMMENDED ACTION** - None\\n* Nov 13, 2020 - CI on the [helm/charts repository](https://github.com/helm/chart) will be disabled and no more Pull Requests will be accepted.\\n * **RECOMMENDED ACTION** - For more info on the ongoing initiative to relocate charts to new repos please see [this issue](https://github.com/helm/charts/issues/21103).\\n* *After* Nov 13, 2020 - Downloads of Charts at their old locations will be re-directed to the read-only archive available in GitHub Pages. The old locations may no longer be available after this date.\\n * **RECOMMENDED ACTION** - See info on [switching to the archived stable and incubator charts](https://helm.sh/docs/faq/#i-am-getting-a-warning-about-unable-to-get-an-update-from-the-stable-chart-repository). Keep in mind that these charts will no longer be updated with bug fixes or security patches.\\n\\n\\n## References\\n\\n* [Charts Repo Deprecation Timeline](https://github.com/helm/charts/issues/23944)\\n* [Relocation of package history](https://github.com/helm/charts/issues/23850)\\n* [Request to transition Helm Chart hosting to CNCF](https://github.com/helm/community/issues/114)"},{"id":"new-location-stable-incubator-charts","metadata":{"permalink":"/blog/new-location-stable-incubator-charts","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-10-26-new-location-stable-incubator-charts.md","source":"@site/blog/2020-10-26-new-location-stable-incubator-charts.md","title":"New Location For Stable and Incubator Charts","description":"As previously announced, the stable and incubator repositories have moved to a new location. This post will update you on the new locations and provide directions to start using them.","date":"2020-10-26T00:00:00.000Z","tags":[],"readingTime":4.47,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"New Location For Stable and Incubator Charts","slug":"new-location-stable-incubator-charts","authors":["mattfarina"],"date":"2020-10-26"},"unlisted":false,"prevItem":{"title":"Helm Chart Repository Deprecation Update","permalink":"/blog/charts-repo-deprecation"},"nextItem":{"title":" Helm Turns 5, and GitHub Gives the Gift of Charts","permalink":"/blog/helm-turns-five"}},"content":"[As previously announced](https://helm.sh/blog/helm-turns-five/), the stable and incubator repositories have moved to a new location. This post will update you on the new locations and provide directions to start using them.\\n\\n_**Important Note:** This does not affect the obsolescence timeline for the stable and incubator repositories that was announced in 2019. On November 13, 2020 the stable and incubator charts repository will reach the end of development and become archives. You can find that many of the charts have moved to other, community managed, repositories. You can discover these on the [Artifact Hub](https://artifacthub.io/). More information on the obsolescence will follow in future blog posts and communications._\x3c!-- truncate --\x3e\\n\\nThe new location for the stable repository is https://charts.helm.sh/stable and the new location for the incubator repository is https://charts.helm.sh/incubator. If you use charts in either of these old locations below you MUST update the repositories you use before November 13, 2020. The new locations are hosted using GitHub pages.\\n\\n| Name | Old Location | New Location |\\n| --------- | ------------ | ------------ |\\n| stable | https://kubernetes-charts.storage.googleapis.com | https://charts.helm.sh/stable |\\n| incubator | https://kubernetes-charts-incubator.storage.googleapis.com | https://charts.helm.sh/incubator |\\n\\n\\
1nAlong with the new locations, Helm v2.17.0 and v3.4.0 have been released to help you use the new location. You are encouraged to upgrade to the latest versions.\\n\\n## Helm v3.4.0\\n\\nHelm v3.4.0 will now detect if you have the stable and incubator repository configured with the old location and warn you that you need to update your configuration to the new location. You can do this using a single command. For example, to update the stable repository that was set with the name `stable` you can run:\\n\\n```\\nhelm repo add stable https://charts.helm.sh/stable --force-update\\n```\\n\\nThis command will also work on Helm v3 versions prior to v3.4.0. You can use it without updating to the latest Helm v3 release.\\n\\nIn addition to that, if you try to use `helm repo add` to add one of the repositories at the old location Helm v3.4.0 and newer will fail to add the repository and warn you to use the new location. Instead of making it automatically add the new location we wanted to make people aware of the location change. If you have a reason to use one of the old locations you can use the new `--allow-deprecated-repos` flag to allow them to be used. The flag will only be useful for as long as the previous location is still operating.\\n\\n## Helm v2.17.0\\n\\nHelm v2 added the stable repository by default when `helm init` was run. This has led to a different solution for Helm v2, starting in v2.17.0.\\n\\nIf you do not need the stable or local repositories, you can use the `--skip-repos` flag when running `helm init`. This is a new flag in v2.17.0. This can have some performance benefits in some use cases such as CI systems where you aren\'t using the stable repository.\\n\\nIn v2.17.0, when `helm init` is run the new location is used instead of the old location. This is what will happen in CI systems that regularly run `helm init`. If you need to continue to use the old location, you can pass the new `--use-deprecated-stable-repository` flag to `helm init`. This will only work for as long as the old locations continue to operate.\\n\\nIf you already have an old location configured for the stable or incubator repository, Helm will warn you that you need to switch to the new location. Doing this in Helm v2 is a little different from v3. You will need to use two commands. For example, to change the `stable` repository you can run:\\n\\n```\\nhelm repo rm stable\\nhelm repo add stable https://charts.helm.sh/stable\\n```\\n\\nThis command will work on Helm v2 versions prior to v2.17.0. You can use it without updating to the latest Helm v2 release.\\n\\n_Note: In addition to the stable and incubator repositories moving to GitHub Pages, the default location for [Tiller has moved to GitHub Container Repository (ghcr.io)](https://github.com/orgs/helm/packages/container/package/tiller). [Tiller is still available from GCR](https://gcr.io/kubernetes-helm/tiller) (its previous home). You can also get Tiller from [Docker Hub](https://hub.docker.com/r/helmpack/tiller) and [Quay](http://quay.io/helmpack/tiller). To specify a non-default location for Tiller you can use the `-i` or `--tiller-image` flag when running `helm init`._\\n\\n## Host Your Own Copy\\n\\nThere are cases where you may control where Helm can make network calls to and you do not want Helm to make calls to GitHub pages. One option, if you need some charts from the stable or incubator repository, is to host a copy of the chart and chart versions you need in your own repository. You could host this repository with [ChartMuseum](https://github.com/helm/chartmuseum), [Harbor](https://goharbor.io/), a static web server, or another system.\\n\\nScott Rigby, one of the Helm Org and Charts maintainers, has created [a script that can copy all or some of the charts and their histories](https://github.com/scottrigby/helm-adopt-package-history) (previous chart versions). This tool, and those like it, can be used to make copies of the charts you use. This can be served from an alternative location.\\n\\nIn Helm v2, you can specify an alternative location for the stable repository when running `helm init` by using the `--stable-repo-url` flag."},{"id":"helm-turns-five","metadata":{"permalink":"/blog/helm-turns-five","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-10-19-helm-turns-five.md","source":"@site/blog/2020-10-19-helm-turns-five.md","title":" Helm Turns 5, and GitHub Gives the Gift of Charts","description":"Happy 5th Birthday Helm","date":"2020-10-19T00:00:00.000Z","tags":[],"readingTime":1.72,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"},{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":" Helm Turns 5, and GitHub Gives the Gift of Charts","slug":"helm-turns-five","authors":["mattbutcher","mattfarina"],"date":"2020-10-19"},"unlisted":false,"prevItem":{"title":"New Location For Stable and Incubator Charts","permalink":"/blog/new-location-stable-incubator-charts"},"nextItem":{"title":"Helm Hub Moving To Artifact Hub","permalink":"/blog/helm-hub-moving-to-artifact-hub"}},"content":"\\n\\nFive years ago, in a hackathon at Deis (who has since been acquired by Microsoft) Helm was born.\x3c!-- truncate --\x3e\\n\\n```\\ncommit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d\\nAuthor: Matt Butcher <[email protected]>\\nDate: Mon Oct 19 17:43:26 2015 -0600\\n\\n initial add\\n```\\n\\n[This commit](https://github.com/helm/helm-classic/commit/ecad6e2ef9523a0218864ec552bbfc724f0b9d3d) can be found on the helm-classic Git repository where the codebase for Helm v1 is located. This is the original Helm, before it merged with Deployment Manager and was folded into Kubernetes. This is where it all began.\\n\\nSince day one, the Helm project has relied upon GitHub for source control, pull request management, and issue tracking. As a graduated CNCF project, the Helm org now manages dozens of GitHub repositories.\\n\\nBut when it came to hosting the packaged charts, we stored them in an object storage bucket hosted on Google Cloud. This historical decision reflects that at that time Google was one of the principal contributors to Helm.\\n\\nRecently, Google\u2019s time of supporting the official Helm chart repository has come to a close. We are grateful for Google\u2019s hosting the Helm chart repository these last few years. But this event has given us an opportunity to further integrate our chart development pipeline with GitHub.\\n\\n\\n\\nSo for today\u2019s birthday celebration, we would like to announce that the Helm `stable` and `incubator` chart repositories will be directly hosted out of GitHub. Furthermore, GitHub Actions will power the pipeline for publishing charts. And thanks to GitHub\u2019s blazingly fast network, chart downloads are faster than ever!\\n\\nWe have even published official Helm GitHub Actions in the GitHub marketplace. Check out [Helm Chart Releaser](https://github.com/marketplace/actions/helm-chart-releaser) for a way to host Helm charts in GitHub.\\n\\nWhile Helm 2 is at the end of its support, we did also move the [official Tiller Docker images](https://github.com/orgs/helm/packages) to GitHub\u2019s container registry.\\n\\nWe are deeply appreciative of GitHub\u2019s tooling and their support for open source projects of all sizes.\\n\\nHappy Birthday, Helm!"},{"id":"helm-hub-moving-to-artifact-hub","metadata":{"permalink":"/blog/helm-hub-moving-to-artifact-hub","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-10-07-helm-hub-moving-artifact-hub.md","source":"@site/blog/2020-10-07-helm-hub-moving-artifact-hub.md","title":"Helm Hub Moving To Artifact Hub","description":"Today, we are happy to announce that the Helm Hub is moving to the Artifact Hub. That means, when you go to the Helm Hub you will be redirected to the Artifact Hub.","date":"2020-10-07T00:00:00.000Z","tags":[],"readingTime":2.43,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm Hub Moving To Artifact Hub","slug":"helm-hub-moving-to-artifact-hub","authors":["mattfarina"],"date":"2020-10-07"},"unlisted":false,"prevItem":{"title":" Helm Turns 5, and GitHub Gives the Gift of Charts","permalink":"/blog/helm-turns-five"},"nextItem":{"title":"Helm v2 Deprecation Timeline","permalink":"/blog/helm-v2-deprecation-timeline"}},"content":"Today, we are happy to announce that the Helm Hub is moving to the [Artifact Hub](https://artifacthub.io/). That means, when you go to the Helm Hub you will be redirected to the Artifact Hub.\x3c!-- truncate --\x3e\\n\\n## What This Means For You\\n\\nIf you search the Helm Hub or list your charts in the Helm Hub you might wonder, what does this mean for me?\\n\\nThe Artifact Hub lists all of the same charts the Helm Hub has listed. It provides search that is faster and includes [faceted search](https://en.wikipedia.org/wiki/Faceted_search). You should be able to discover charts in a similar way to what you did before. Searching continues to work with the Helm CLI, as well.\\n\\nThere is more in the Artifact Hub than just searching for charts. You can get notifications via email or web hook when a chart is updated. You can find other artifacts and see related artifacts. The Artifact Hub provides more than the Helm Hub did.\\n\\nIf you listed your chart repositories in the Helm Hub and didn\'t already have them listed in the Artifact Hub, they were automatically brought over. The Artifact Hub provides a means to claim your repository as well as list new ones. When listing a repository you can connect it to a user account or a multi-user organization.\\n\\n## Why We Are Doing This\\n\\nThe Helm Hub was built on the Monocular project. This project was built to handle a limited number of Helm repositories and was designed for a slightly different use case than a public listing of as many chart repositories as possible. It served the Helm project well but has begun to show some limitations as the number of Helm charts and repositories grew. We knew we needed to do something about this problem with the Helm Hub.\\n\\nThe Artifact Hub came along as we were starting to experience growth issues. Instead of operating our own instance of the Artifact Hub or writing our own software to handle the scaling issues, we are deferring to the Artifact Hub to handle chart discovery and management. The Artifact Hub supports and promotes more of the CNCF ecosystem than just charts.\\n\\n## Questions, Concerns, or Issues\\n\\nIf you experience issues with the changeover please let us know. There are a few ways you can do this:\\n\\n1. If the issue is claiming your chart repository on the Artifact Hub from the migration, please file an issue on the [Helm Hub repository](https://github.com/helm/hub).\\n2. Experiencing a problem with the Artifact Hub site, then you can file an issue with the [Artifact Hub project](https://github.com/artifacthub/hub). It is a CNCF project and open source.\\n3. Having problems using the Helm CLI to search the Artifact Hub? You can file an issue with [Helm](https://github.com/helm/helm). Note, URLs for charts will still begin with `hub.helm.sh`, by default, when found in search."},{"id":"helm-v2-deprecation-timeline","metadata":{"permalink":"/blog/helm-v2-deprecation-timeline","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-08-13-helm-v2-deprecation-timeline.md","source":"@site/blog/2020-08-13-helm-v2-deprecation-timeline.md","title":"Helm v2 Deprecation Timeline","description":"with a nod to Lewis Carroll...","date":"2020-08-12T00:00:00.000Z","tags":[],"readingTime":3.13,"hasTruncateMarker":true,"authors":[{"name":"Bridget Kromhout","page":{"permalink":"/blog/authors/bridgetkromhout"},"socials":{"github":"https://github.com/bridgetkromhout","linkedin":"https://www.linkedin.com/in/bridgetkromhout/"},"imageURL":"https://github.com/bridgetkromhout.png","key":"bridgetkromhout"}],"frontMatter":{"title":"Helm v2 Deprecation Timeline","slug":"helm-v2-deprecation-timeline","authors":["bridgetkromhout"],"date":"2020-08-12"},"unlisted":false,"prevItem":{"title":"Helm Hub Moving To Artifact Hub","permalink":"/blog/helm-hub-moving-to-artifact-hub"},"nextItem":{"title":"Celebrating Helm\'s CNCF Graduation","permalink":"/blog/celebrating-helms-cncf-graduation"}},"content":"_[with a nod to Lewis Carroll...](https://www.jabberwocky.com/carroll/walrus.html)_\\n\\n \u201CThe time has come,\u201D the maintainers said,\\n \u201CTo talk of software fates:\\n Of upgrades -- and shipping Helm v3 --\\n Of bugfixes -- and k8s --\u201D\\n\\n[Helm v3 was released in November 2019](/blog/helm-3-released/), the result of ongoing community effort to evolve Helm to meet the community\u2019s needs. With a streamlined client-only experience, a renewed focus on security, and tighter integration with Kubernetes APIs, Helm v3 continues to provide production-tested package management for Kubernetes. And as a [graduated CNCF project](/blog/celebrating-helms-cncf-graduation/), Helm is a key part of the cloud native ecosystem.\\n\x3c!-- truncate --\x3e\\n\\nWe recognize that rolling out a major version change in production requires time. The Helm maintainers committed to providing bugfixes for Helm v2 until May 2020 (which they [extended to August 2020](/blog/covid-19-extending-helm-v2-bug-fixes/)) and security patches for Helm v2 until November 2020. And now the bugfix window is closing;
1 [Helm v2.16.10](https://github.com/helm/helm/releases/tag/v2.16.10) will be the final bugfix release and 2.17.0 will follow with the [download location updated](https://github.com/helm/helm/issues/8346).\\n\\n## What does this mean for Helm users?\\n\\n_After August 13, 2020, you will see these changes:_\\n- If you\u2019re still using Helm v2, you will want to [migrate to Helm v3](/blog/migrate-from-helm-v2-to-helm-v3/) now. Helm 3.2.4 is widely used and production-ready. While largely backwards-compatible, there are specific changes you\u2019ll want to be aware of when carrying out your migration.\\n- Starting now, ongoing support of Helm v2 is limited to the next three months of security patches. That means we will no longer be accepting pull requests for anything but verified security issues.\\n- The `stable` and `incubator` repos will be de-listed from the Helm Hub, [introduced in December 2018](/blog/intro-helm-hub/). Find your preferred repositories on [Helm Hub](https://hub.helm.sh) to add them to your configs, and [track the migration of charts to their new decentralized locations](https://github.com/helm/charts/issues/21103).\\n\\n\\n_After November 13, 2020, you will see these changes:_\\n- No further Helm v2 releases (even for security patches)\\n- No further updates to [Helm v2 documentation](https://v2.helm.sh/docs), which will remain available for the present time but may be discontinued\\n- Existing and new issues/PRs that are v2-specific will be closed\\n- [Transitioning Helm release and chart hosting ownership to CNCF](https://github.com/helm/community/issues/114)\\n\\n| | |\\n| - | - |\\n| To Be Removed | Replacement |\\n| Download links for the Helm v2 client through Google Cloud Storage | Client downloads through [get.helm.sh](/blog/get-helm-sh/)|\\n| Docker image for Tiller stored in Google Container Registry | We will distribute a Tiller image that will be [made available at an alternative location](https://github.com/helm/helm/issues/8346) which can be updated with helm init --tiller-image. |\\n| Google Cloud buckets for the stable and incubator chart repositories | \u201CStable\u201D and \u201Cincubator\u201D repositories discontinued; https://github.com/helm/charts marked as obsolete |\\n\\nThe community has found Helm v3 to be a vastly improved experience, and community resources like the [helm-2to3 plugin](https://github.com/helm/helm-2to3) are available to assist you in your essential migration. Please ensure that you migrate to Helm v3 before the November 13th deadline, as operating software which no longer receives security patches is a risk best avoided.\\n\\nWe want to take this moment to thank everyone in the community who has used Helm or contributed an issue or pull request to help improve it. Many great ideas that don\u2019t fit into Helm itself have much success as [related ecosystem projects](/community/related). Every time you submit updates to the docs, you\u2019re helping others get started and be more effective with Helm. Thank you all!"},{"id":"celebrating-helms-cncf-graduation","metadata":{"permalink":"/blog/celebrating-helms-cncf-graduation","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-04-30-celebrating-helms-cncf-graduation.md","source":"@site/blog/2020-04-30-celebrating-helms-cncf-graduation.md","title":"Celebrating Helm\'s CNCF Graduation","description":"images/helmgraduation.png","date":"2020-04-30T00:00:00.000Z","tags":[],"readingTime":4.17,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"}],"frontMatter":{"title":"Celebrating Helm\'s CNCF Graduation","slug":"celebrating-helms-cncf-graduation","authors":["mattbutcher"],"date":"2020-04-30"},"unlisted":false,"prevItem":{"title":"Helm v2 Deprecation Timeline","permalink":"/blog/helm-v2-deprecation-timeline"},"nextItem":{"title":"COVID-19: Extending Helm v2 Bug Fixes","permalink":"/blog/covid-19-extending-helm-v2-bug-fixes"}},"content":"\\n\\nToday we are happy to see Helm [reach the final stage of the CNCF ladder](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/). Helm has moved from the incubating level to the graduated level as a [CNCF project](https://www.cncf.io/projects/), alongside Kubernetes and other select projects.\x3c!-- truncate --\x3e\\n\\nGiven Helm\'s humble beginnings as a hackathon project at Deis, a small startup, we are ecstatic to see our little baby all grown up. And we have certainly learned a lot about coding, community, and organizational politics over the last five years. But those are not the big reasons why we are celebrating Helm\'s graduation.\\n\\nSeveral months after Helm got started, we be
1came a sub-project of Kubernetes itself. It was early 2016, and in short order we had gone from a side project to a viable package manager in the Kubernetes ecosystem. While Kubernetes had focused on the SRE and DevOps story, not masking complexity, Helm took a different approach. During a meeting in February of 2016, [Michelle Noorali](https://twitter.com/michellenoorali) wrote the following phrase on our whiteboard: \\"Zero to dopamine in five minutes.\\" That was our Helm mantra: We saw an opportunity to make Kubernetes more approachable to newcomers. If we did things right, users could install Helm and then within minutes be installing production-grade off-the-shelf components.\\n\\nThese days, Helm is [used by over 70% of Kubernetes users](https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf), from college students to major cloud providers. But we are most proud when we hear stories of Kubernetes newcomers getting up and running quickly because of Helm.\\n\\nBe that as it may, Helm\'s graduation marks a second distinction. Since the first commits to Helm, we called it \\"the package manager for Kubernetes,\\" meaning that our overall design focus would be enabling redistribution, installation, upgrade, and deletion of bundles of Kubernetes resource definitions. Our goal was to be for Kubernetes what homebrew is to macOS, apt-get is to Debian/Ubuntu, and Chocolatey is to Windows.\\n\\nAt the time, it seemed like a modest goal. After all, Kubernetes (at version 1.2) had very few users. But Kubernetes exploded in popularity. A few notable companies began running it in production. Then major cloud providers built hosted Kubernetes offerings. And then large enterprises known for focusing on stability rather than shininess also began using Kubernetes in earnest. This was an acid test for Helm. Could we meet the needs of hundreds of thousands of users, all with different goals and desires? It appears so.\\n\\nThe term \\"graduation\\" confers the idea that a notable set of requirements has been completed. While we are thrilled to have a tremendous user base, CNCF publishes a list of criteria designed to test for enterprise-readiness. Stability, security, healthy governance, strong community -- these things are an absolute necessity if a large open source project is to succeed.\\n\\nCNCF states that [projects](https://www.cncf.io/projects/) can only graduate when they demonstrate that they are ready for the mainstream majority of users. The list of criteria for moving from incubation to graduation defines what it means to be a stable open source project. Helm took the graduation criteria to heart. Helm didn\'t just pass our security review, we did so with flying colors. We didn\'t just qualify for the [CII badge](https://bestpractices.coreinfrastructure.org/en), we scored a [198% on the certification test](https://bestpractices.coreinfrastructure.org/en/projects?q=helm%20package%20manager). While we only needed two committers from two different companies, we have many, many contributors from all over the globe. And over the years we have repeatedly demonstrated our commitment to open and fair governance.\\n\\nAnd so we stand at this milestone. We completed the last requirement for graduation: the CNCF Technical Oversight Committee (TOC) has voted by supermajority in agreement that Helm is now a top-level project.\\n\\nSo what changes are in store for Helm in the future? Process-wise, things will remain as they already are. We will continue our unwavering commitment to stability and compatibility from major version to major version. We have begun the very earliest investigations into what Helm 4 may have in store. And we are (as always) eager to welcome new participants into our community, from helpful users who want to share their experiences through seasoned experts who wish to contribute substantial time to the upkeep of the project. Moreover, we are excited for the [CNCF\'s Artifact Hub](https://devclass.com/2020/03/12/cncf-starts-new-artifact-hub/) project, which we believe will truly bring together several major movements within CNCF. We are excited to continue working with CNCF\'s community.\\n\\nWe would like to continue our tradition of ending our Helm articles with a huge thank-you to the tens of thousands of community members who have, in ways small and large, contributed to the success of Helm. Here\'s to many more years of providing that \\"zero to dopamine in five minutes\\" experience to all Kubernetes users!"},{"id":"covid-19-extending-helm-v2-bug-fixes","metadata":{"permalink":"/blog/covid-19-extending-helm-v2-bug-fixes","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2020-04-02-covid-19-extending-helm-v2-bug-fixes.md","source":"@site/blog/2020-04-02-covid-19-extending-helm-v2-bug-fixes.md","title":"COVID-19: Extending Helm v2 Bug Fixes","description":"As our world comes together to fight the global pandemic, the Helm maintainers want to ensure that we\'re doing our part to help you maintain your critical systems while they are operating at peak demand in a time where normal development and operation schedules have had to be adju
1sted.","date":"2020-04-03T00:00:00.000Z","tags":[],"readingTime":1.06,"hasTruncateMarker":true,"authors":[],"frontMatter":{"title":"COVID-19: Extending Helm v2 Bug Fixes","slug":"covid-19-extending-helm-v2-bug-fixes","date":"2020-04-03"},"unlisted":false,"prevItem":{"title":"Celebrating Helm\'s CNCF Graduation","permalink":"/blog/celebrating-helms-cncf-graduation"},"nextItem":{"title":"Helm at KubeCon + CloudNativeCon NA 2019","permalink":"/blog/2019/11/15/helm-at-cloudnativecon"}},"content":"As our world comes together to fight the global pandemic, the Helm maintainers want to ensure that we\'re doing our part to help you maintain your critical systems while they are operating at peak demand in a time where normal development and operation schedules have had to be adjusted.\x3c!-- truncate --\x3e\\n\\nWhen Helm v3 was released in November 2019, our original commitment was that we would offer six months of Helm v2 bug fixes, which would end May 13, 2020, followed by six more months of security fixes for Helm v2. Given the expectation that current priorities require a singular focus on fighting the pandemic, we now plan to release Helm v2 bug fixes for an extra three months, until August 13th, 2020, giving Helm users more time for serving their communities\' most immediate needs.\\n\\nWe will monitor the situation to see if any additional adjustments are needed due to these circumstances. All Helm v2 support is currently still planned to end November 13th (with the window for security-only fixes now planned for three months). Join us in our [community calls, chats, mailing lists, and GitHub repositories](https://github.com/helm/community/blob/main/communication.md) if there is anything we can do to help unblock you in critical work, and stay safe!"},{"id":"/2019/11/15/helm-at-cloudnativecon","metadata":{"permalink":"/blog/2019/11/15/helm-at-cloudnativecon","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-11-15-helm-at-cloudnativecon.md","source":"@site/blog/2019-11-15-helm-at-cloudnativecon.md","title":"Helm at KubeCon + CloudNativeCon NA 2019","description":"Next week is the annual KubeCon and CloudNativeCon in North America. The Helm project and maintainers have several things going on and we wanted to invite you to them.","date":"2019-11-15T00:00:00.000Z","tags":[],"readingTime":1.42,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm at KubeCon + CloudNativeCon NA 2019","authors":["mattfarina"],"date":"2019-11-15"},"unlisted":false,"prevItem":{"title":"COVID-19: Extending Helm v2 Bug Fixes","permalink":"/blog/covid-19-extending-helm-v2-bug-fixes"},"nextItem":{"title":"Helm 3.0.0 has been released!","permalink":"/blog/helm-3-released"}},"content":"Next week is the annual [KubeCon and CloudNativeCon in North America](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/). The Helm project and maintainers have several things going on and we wanted to invite you to them.\x3c!-- truncate --\x3e\\n\\nHelm will have two maintainer track sessions that focus on an [_Introduction to Helm_](https://sched.co/UajI) and a [_Helm 3 Deep Dive_](https://sched.co/Uagg). Anyone who is new to Helm or would be interested in learning how and why they should use Helm, please consider attending the _Introduction to Helm_. If you are curious about the [recently released Helm 3](https://helm.sh/blog/helm-3-released/), the _Helm 3 Deep Dive_ is for you. Please let others know about these talks if you think they will interest them!\\n\\nThis year also marks the first time the Helm project will have their own project specific booth! If you want to talk with the maintainers or have other questions about the project, the booth will be an excellent space to meet the people who regularly work on the project.\\n\\nThere are several exciting Helm-centric sessions from the community this year. For example, Ricarto Rocha from CERN will be presenting [_Managing Helm Deployments with Gitops at CERN_](https://sched.
1co/UabD). You can check the schedule to learn about other sessions in the [official schedule](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/schedule/).\\n\\nGoing to be at the conference the weekend before it starts? [Cloud_Native Rejekts](https://cloud-native.rejekts.io/) will be going on and Taylor Thomas, one of the Helm project maintainers, will be presenting [_Advanced Interactions with Kubernetes (As Taught by Helm)_](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-na-2019/talk/SQ9DWX/)."},{"id":"helm-3-released","metadata":{"permalink":"/blog/helm-3-released","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-11-13-helm-3-released.md","source":"@site/blog/2019-11-13-helm-3-released.md","title":"Helm 3.0.0 has been released!","description":"The Helm Team is proud to announce the first stable release of Helm 3.","date":"2019-11-13T00:00:00.000Z","tags":[],"readingTime":5.46,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 3.0.0 has been released!","slug":"helm-3-released","authors":["mattfisher"],"date":"2019-11-13"},"unlisted":false,"prevItem":{"title":"Helm at KubeCon + CloudNativeCon NA 2019","permalink":"/blog/2019/11/15/helm-at-cloudnativecon"},"nextItem":{"title":"Helm Community Management","permalink":"/blog/2019/11/11/community-management"}},"content":"The Helm Team is proud to announce the first stable release of Helm 3.\\n\\nHelm 3 is the latest major release of the CLI tool. Helm 3 builds upon the success of Helm 2, continuing to meet the needs of the evolving ecosystem.\x3c!-- truncate --\x3e\\n\\nThe internal implementation of Helm 3 has changed considerably from Helm 2. The most apparent change is the removal of Tiller, but it\'s worth checking out the other changes by diving into the new release. A rich set of new features have been added as a result of the community\'s input and requirements. Some features have been deprecated or refactored in ways that make them incompatible with Helm 2. Some new experimental features have also been introduced, including OCI support.\\n\\nAdditionally, the Helm Go SDK has been refactored for general use. The goal is to share and re-use code we\'ve open sourced with the broader Go community. We are actively looking for feedback from other engineers integrating Helm in their own projects, and would love to hear from you in the [#helm-dev Kubernetes Slack channel](https://slack.k8s.io/).\\n\\nHere are some Helm 3 resources:\\n\\n- [Documentation](https://helm.sh/docs/)\\n- [FAQ: Changes since Helm 2](https://helm.sh/docs/faq/#changes-since-helm-2)\\n- [Installing Helm](https://helm.sh/docs/intro/install/)\\n- [Documentation on Helm 2 to Helm 3 migration](https://helm.sh/docs/topics/v2_v3_migration/)\\n- [Plugin to help migrate from Helm 2 to Helm 3](https://github.com/helm/helm-2to3)\\n- Chat with developers and contributors in the [#helm-users Kubernetes Slack channel](https://slack.k8s.io/)\\n- Please report bugs at <https://github.com/helm/helm/issues>\\n\\n## What is Helm?\\n\\nHelm gives teams the tools they need to collaborate when creating, installing, and managing applications inside of Kubernetes.\\n\\nWith Helm, you can...\\n\\n- Find prepackaged software (charts) to install and use\\n- Easily create and host your own packages\\n- Install packages into any Kubernetes cluster\\n- Query the cluster to see what packages are installed and running\\n- Update, delete, rollback, or view the history of installed packages\\n\\nHelm makes it easy to run applications inside Kubernetes.\\n\\n## Let\'s see it!\\n\\nAssuming you have a Kubernetes cluster running and a correctly configured `kubectl`, working with Helm is a piece of cake.\\n\\nHelm makes it easy to search for new charts by adding repositories hosted by the community.\\n\\n```bash\\n$ helm repo add nginx https://helm.nginx.com/stable\\n```\\n\\nOnce you\'ve added a few repositories, you can search for charts:\\n\\n```bash\\n$ helm search repo nginx-ingress\\nNAME CHART VERSION APP VERSION DESCRIPTION\\nnginx/nginx-ingress 0.3.7 1.5.7 NGINX Ingress Controller\\n```\\n\\nHelm gives you a quick way to install that chart with `helm install`:\\n\\n```bash\\n$ helm install my-ingress-controller nginx/nginx-ingress\\n```\\n\\nIf we inspect the cluster with `kubectl`:\\n\\n```bash\\n$ kubectl get deployments\\n```\\n\\nWe have an ingress controller running! We can just as easily remove it with `helm uninstall my-ingress-controller`.\\n\\nOkay. You\'ve tried some charts. You\'ve customized a few. And now you\'re ready to build your own. Helm makes that part easy, too.\\n\\n```bash\\n$ helm create diy\\nCreating diy\\n```\\n\\nNow you have a new chart named `diy`. You could go to that directory and edit it, run `helm template` to view the rendered output, or install it with `helm install`.\\n\\nWant to submit it upstream to the [Helm Hub](https://hub.helm.sh/)? Please do! Make sure to follow the documentation on [adding your own repositories](https://github.com/helm/hub/blob/master/Repositories.md) to the Helm Hub.\\n\\n## What changed in Helm 3?\\n\\nYou may be asking yourself at this point:\\n\\n> How did the workflow change from Helm 2? If I run those commands with Helm 2, will I see the same output?\\n\\nHelm 2 described a workflow for creating, installing, and managing charts. Helm 3 builds upon that workflow, changing the underlying infrastru
1cture to meet the needs of the evolving ecosystem.\\n\\nIf you\'re comfortable with Helm 2, you\'ll feel right at home with Helm 3.\\n\\nTo learn more about what changed under the hood, [check out the FAQ](https://helm.sh/docs/faq/) in the documentation. A list of changes and explanations for the changes involved are provided there.\\n\\n## The Future of Helm\\n\\nThe core maintainers are really excited to release Helm 3.0. Helm\'s next phase of development will see new features targeted toward stability and enhancements to existing features. Features on the road map include:\\n\\n- Enhanced functionality for `helm test`\\n- Improvements to Helm\'s OCI integration\\n- Enhanced functionality for the Go client libraries\\n\\n### Helm 2 Support Plan\\n\\nIn the Helm 2.15.0 release announcement, we shared details about the future plans for Helm 2. You can read more about those plans in [the announcement post](https://helm.sh/blog/2019-10-22-helm-2150-released/).\\n\\n## Relation of Helm 3 to Helm 1 and 2\\n\\nIn November 2015, the first version of Helm was released at the first KubeCon. Modeled on the macOS software installer [Homebrew](https://brew.sh/), Helm 1 (known by the team as \\"Helm Classic\\") was designed to help individual developers create packages of Kubernetes resources and deploy them into a cluster.\\n\\nA few months later (January 2016), Deis\u2019 core Helm team joined forces with Google, Skippbox, and (shortly thereafter) Bitnami to produce a new version of Helm that shifted emphasis from individuals to teams. Along the way, we applied many of the lessons we\u2019d learned. The result was a tool designed to not only make teamwork a central value, but also meet the needs of a burgeoning community of Kubernetes users who are installing sophisticated applications.\\n\\nIn June 2018, Helm [joined the Cloud Native Computing Foundation](https://helm.sh/blog/helm-enters-the-cncf/). Helm 3 became a joint community effort, with core maintainers including members from Microsoft, Samsung SDS, IBM, and Blood Orange. Since the first alpha release, Helm 3 has seen contributions from 37 different members of the community, spanning across many time zones. The end result is a tool that reflects the needs of its community as those change and evolve over time.\\n\\n## Conclusion\\n\\nWe set out to build a tool that is an on-ramp to Kubernetes. We wanted to make it easier for the Kubernetes user to create, share, and run production-grade workloads.\\n\\nOver 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. This is a credit to the colossal efforts of the Kubernetes community which has transformed this project from a simple Deis installer into a power tool for all Kubernetes users.\\n\\nThank you all, and see you on GitHub!\\n\\n- The Helm Team :heart:"},{"id":"/2019/11/11/community-management","metadata":{"permalink":"/blog/2019/11/11/community-management","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-11-11-community-management.md","source":"@site/blog/2019-11-11-community-management.md","title":"Helm Community Management","description":"Devstats and stats on GitHub are able to capture many different types of contributions to an open source project. But there is one type of contribution for which we have yet to figure out a good metric, and it has been essential for Helm\'s success. That is community management.","date":"2019-11-11T00:00:00.000Z","tags":[],"readingTime":1.3,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm Community Management","authors":["mattfarina"],"date":"2019-11-11"},"unlisted":false,"prevItem":{"title":"Helm 3.0.0 has been released!","permalink":"/blog/helm-3-released"},"nextItem":{"title":"Helm Security Audit Results","permalink":"/blog/2019/11/04/helm-security-audit-results"}},"content":"[Devstats](https://helm.devstats.cncf.io/) and stats on GitHub are able to capture many different types of contributions to an open source project. But there is one type of contribution for which we have yet to figure out a good metric, and it has been essential for Helm\'s success. That is community management.\\n\\nKaren Chu has handled community management for Helm since the project was first announced at the inaugural KubeCon in San Francisco. Her work ranges from big things, like planning and executing two Helm Summits, down to smaller (but still essential) things like managing the [Helm twitter account](https://twitter.com/HelmPack).\x3c!-- truncate --\x3e\\n\\nUntil this point, Karen\'s role has been pseudo-official. There has been no Helm related title or sub-project of Helm for this work. We are happy to announce that we have now rectified the situation by formalizing community management as a sub-project of Helm with Karen as the person running the show.\\n\\nCommunity managers do so much to make open source successful. Dave Neary, a community architect at Red Hat, highlighted some of the areas of value they bring in [a post about the roles filled by a community manager](https://community.redhat.com/blog/2018/01/the-many-faces-of-the-community-manager/). He talked about activities ranging from partnerships to developer enablement. We look forward to Karen\'s continued contributions in this space!\\n\\nIf you want to learn more about community management, Karen is part of a panel at KubeCon + CloudNativeCon North America 2019 entitled [\\"What\u2019s Essential in an OSS Project Launch Playbook?\\"](https://sched.
1co/Uabt)."},{"id":"/2019/11/04/helm-security-audit-results","metadata":{"permalink":"/blog/2019/11/04/helm-security-audit-results","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-11-04-helm-security-audit-results.md","source":"@site/blog/2019-11-04-helm-security-audit-results.md","title":"Helm Security Audit Results","description":"Today, the Helm Maintainers are proud to announce that we have successfully completed a 3rd party security audit for Helm 3. Helm has been recommended for public deployment.","date":"2019-11-04T00:00:00.000Z","tags":[],"readingTime":2.33,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm Security Audit Results","authors":["mattfarina"],"date":"2019-11-04"},"unlisted":false,"prevItem":{"title":"Helm Community Management","permalink":"/blog/2019/11/11/community-management"},"nextItem":{"title":"Helm Vulnerability: Client Loading and Packaging Chart Directory Containing Malicious Symlinked Content [CVE-2019-18658]","permalink":"/blog/2019/10/30/helm-symlink-security-notice"}},"content":"Today, the Helm Maintainers are proud to announce that we have successfully completed a 3rd party security audit for Helm 3. Helm has been recommended for public deployment.\\n\\nA security audit is part of the graduation criteria for CNCF projects. Specifically, the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc#graduation-stage) says:\\n\\n> Have completed an independent and third party security audit with results published of similar scope and quality as the following example (including critical vulnerabilities addressed): https://github.com/envoyproxy/envoy#security-audit and all critical vulnerabilities need to be addressed before graduation.\x3c!-- truncate --\x3e\\n\\nDuring October, the CNCF funded [Cure53](https://cure53.de/) to perform a security audit of Helm version 3. Cure53 has performed audits of other CNCF projects including Prometheus, Envoy, Jaeger, Notary, and others.\\n\\nA [report from the security audit is available in the Helm community repo](https://github.com/helm/community/blob/main/security-audit/HLM-01-report.pdf). We recommend that you take a look at it for the details. The report covers their process, what they reviewed, and what they found. Their review included, but was not limited to:\\n\\n* The programming language used along with patterns and the use of external libraries\\n* Access control which is different in Helm v3 than in Helm v2 due to the removal of Tiller\\n* How logging and monitoring are handled\\n* Unit and regression testing\\n* Documentation, including the security contacts and process\\n* The process for fixing security issues\\n* The software used for signing and verification of Helm charts\\n* Manipulation of chart files\\n* TLS handling for communications\\n\\nFrom the Cure53 analysis there was only one noteworthy finding and it did not lead not an exploit. While the audit and issue were found to be in Helm v3 we also found the issue was present in Helm v2. Since Helm v2 has stable releases we announced a [security vulnerability](https://helm.sh/blog/2019-10-30-helm-symlink-security-notice/) and created a CVE.\\n\\nThe [entire report](https://github.com/helm/community/blob/main/security-audit/HLM-01-report.pdf) is worth reading as no summary can do it justice. Cure53 provided a conclusion as part of their summary which reads:\\n\\n> To conclude, in light of the findings stemming from this CNCF-funded project, Cure53 can only state that the Helm project projects the impression of being highly mature. This verdict is driven by a number of different factors described above and essentially means that Helm can be recommended for public deployment, particularly when properly configured and secured in accordance to recommendations specified by the development team.\\n\\nSecurity audits are one of the benefits of CNCF projects and we are grateful for them and the analysis performed by Cure53. This analysis has provided some concrete areas we can work to improve and given us confidence in what we have."},{"id":"/2019/10/30/helm-symlink-security-notice","metadata":{"permalink":"/blog/2019/10/30/helm-symlink-security-notice","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-10-30-helm-symlink-security-notice.md","source":"@site/blog/2019-10-30-helm-symlink-security-notice.md","title":"Helm Vulnerability: Client Loading and Packaging Chart Directory Containing Malicious Symlinked Content [CVE-2019-18658]","description":"Part of the process for Helm to become a graduated CNCF project is to complete an independent and third party security audit with the results being published. As part of the audit of Helm 3 a security issue was found that also impacts Helm v2. Cure53 performed the audit and found the issue. More about the audit will be covered in a future post.","date":"2019-10-30T00:00:00.000Z","tags":[],"readingTime":2.01,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm Vulnerability: Client Loading and Packaging Chart Directory Containing Malicious Symlinked Content [CVE-2019-18658]","authors":["mattfarina"],"date":"2019-10-30"},"unlisted":false,"prevItem":{"title":"Helm Security Audit Results","permalink":"/blog/2019/11/04/helm-security-audit-results"},"nextItem":{"title":"Helm 2.15.0 Released","permalink":"/blog/2019/10/22/helm-2150-released"}},"content":"Part of the process for Helm to become a graduated CNCF project is to complete an independent and third party security audit with the results being published. As part of the audit of Helm 3 a security issue was found that also impacts Helm v2. [Cure53](https://cure53.de/) performed the audit and found the issue. More about the audit will be covered in a future post.\\n\\nThe vulnerability found impacts **all versions of Helm between Helm >=2.0.0 and < 2.15.2**. Helm commands that deal with loading a chart as a directory or packaging a chart provide an opportunity for a maliciously designed chart to include content not intended in the chart or to execute a denial of service (DOS) on the computer performing the packaging via the use of symlinks.\x3c!-- truncate --\x3e\\n\\nNo version of Tiller is known to be impacted. This is a client-only issue.\\n\\nThe following Helm commands may unsafely handle malformed charts: `helm package`, `helm install`, `helm upgrade`, and `helm dependency build`.\\n\\nWe are unaware of any public exploits caused by this issue.\\n\\n## Details\\n\\nHelm charts can include symlinks. This feature provides a means of symlinking chart dependencies together when stored in a filesystem. Two types of symlinks can cause vulnerabilities.\\n\\n1. A symlink to a specially crafted file on the targets system. For example, a file containing sensitive information. When someone runs `helm package` this symlinked file will be copied into the archive without any notification. When the packaged file is moved elsewhere, such as to a Helm repository, the sensitive file will be sent along.\\n2. A symlink to a special file, such as a device driver. For example, a symlink to `/dev/urandom`. This would cause a command like `helm install` or `helm package` to continuously read from `/dev/urandom` as it tries to create the payload.\\n\\nNo Tiller version is impacted. This vulnerability does not render cluster
1s vulnerable to attack. Tiller does not load chart directories.\\n\\n## Workarounds\\n\\nA process work around can be used to mitigate the vulnerability. Do not load chart directories or package charts whose contents you do not trust or in an environment with sensitive information.\\n\\n## Fix\\n\\nUpdate to Helm >= 2.15.2.\\n\\nAs of Helm 2.15.2, Helm will log to output all of the symlinked files referenced when packaging a chart and it will return an error while failing to load chart directories containing symlinks to irregular files (e.g., device or unix socket)."},{"id":"/2019/10/22/helm-2150-released","metadata":{"permalink":"/blog/2019/10/22/helm-2150-released","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-10-22-helm-2150-released.md","source":"@site/blog/2019-10-22-helm-2150-released.md","title":"Helm 2.15.0 Released","description":"Helm 2.15.0 was released last week. The 2.15.0 release of Helm introduces several improvements to helm test. Several commands - helm search, helm repo list, and helm install - received the --output flag for machine-readable output.","date":"2019-10-22T00:00:00.000Z","tags":[],"readingTime":2.33,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 2.15.0 Released","authors":["mattfisher"],"date":"2019-10-22"},"unlisted":false,"prevItem":{"title":"Helm Vulnerability: Client Loading and Packaging Chart Directory Containing Malicious Symlinked Content [CVE-2019-18658]","permalink":"/blog/2019/10/30/helm-symlink-security-notice"},"nextItem":{"title":"How to migrate from Helm v2 to Helm v3","permalink":"/blog/migrate-from-helm-v2-to-helm-v3"}},"content":"[Helm 2.15.0](https://github.com/helm/helm/releases/tag/v2.15.0) was released last week. The 2.15.0 release of Helm introduces several improvements to `helm test`. Several commands - `helm search`, `helm repo list`, and `helm install` - received the `--output` flag for machine-readable output.\\n\\nIn addition to these new features (and many more!), many bugs and edge cases in Helm continue to fixed by members of the community. Several parts of the codebase have been refactored for easier maintainability, usability, and better testing.\\n\\nAs Helm moves towards Helm 3\'s first release, Helm 2 is now transitioning into \\"maintenance mode\\". Helm 2.15.0 will be the final feature release for Helm 2.\x3c!-- truncate --\x3e\\n\\n## Helm 2 support plan\\n\\nDuring the transition, we want to take into account any migration issues for users. We also want to clarify what actions may occur after the support contract ends for Helm 2, so that users will not be surprised or caught off guard.\\n\\nFor Helm 2, we will continue to accept bug fixes and fix any security issues that arise, but no new features will be accepted. All feature development will be moved over to Helm 3.\\n\\n6 months after Helm 3\'s public release, Helm 2 will stop accepting bug fixes. Only security issues will be accepted.\\n\\n12 months after Helm 3\'s public release, support for Helm 2 will formally end. Download links for the Helm 2 client through Google Cloud Storage, the Docker image for Tiller stored in Google Container Registry, and the Google Cloud buckets for the stable and incubator chart repositories may no longer work at any point. Client downloads through get.helm.sh will continue to work, and we will distribute a Tiller image that will be made available at an alternative location which can be updated with `helm init --tiller-image`.\\n\\n## The big branch switch\\n\\nEver since Helm 3\'s initial development, the core maintainers and the community have been pushing commits for Helm 3 to the `dev-v3` branch, and pushing commits for Helm 2 to the `master` branch. As Helm 3 now becomes the main development branch for all future work, we decided to switch the main trunk of the Helm repository over to Helm 3\'s development branch.\\n\\nWith Helm 2 transitioning into maintenance mode, now was a good opportunity to switch branches over.\\n\\nEarlier this week, the transition was completed with no downtime. Moving forward, bug fixes for Helm 2 should target the `dev-v2` branch. Features and bug fixes for Helm 3 should target the `master` branch.\\n\\n## Parting thoughts\\n\\nThe Helm team would like to thank the community for [nearly 3 years of contributions](https://github.com/helm/helm/releases/tag/v2.0.0) and [over 5,000 commits](https://github.com/helm/helm/tree/dev-v2) towards Helm 2 since its initial release.\\n\\nOnwards and upwards!"},{"id":"migrate-from-helm-v2-to-helm-v3","metadata":{"permalink":"/blog/migrate-from-helm-v2-to-helm-v3","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-09-11-migrate-from-helm-v2-to-helm-v3.md","source":"@site/blog/2019-09-11-migrate-from-helm-v2-to-helm-v3.md","title":"How to migrate from Helm v2 to Helm v3","description":"Diagram how to migrate from Helm 2 to 3","date":"2019-09-11T00:00:00.000Z","tags":[],"readingTime":11.57,"hasTruncateMarker":true,"authors":[{"name":"Rimas Mocevicius","page":{"permalink":"/blog/authors/rimasmocevicius"},"socials":{"github":"https://github.com/rimusz","linkedin":"https://www.linkedin.com/in/rimantasmocevicius/","website":"https://rimusz.net/"},"imageURL":"https://github.com/rimusz.png","key":"rimasmocevicius"}],"frontMatter":{"title":"How to migrate from Helm v2 to Helm v3","slug":"migrate-from-helm-v2-to-helm-v3","authors":["rimasmocevicius"],"date":"2019-09-11"},"unlisted":false,"prevItem":{"title":"Helm 2.15.0 Released","permalink":"/blog/2019/10/22/helm-2150-released"},"nextItem":{"title":"Helm v3 Beta 1 Released","permalink":"/blog/helm-v3-beta"}},"content":"\\n\\nOne of the most important parts of upgrading to a new major release of Helm is the migration of data. This is especially true of Helm v2 to v3 considering the architectural changes between the releases. This is where the [helm-2to3](https://github.com/helm/helm-2to3) plugin comes in.\\n\x3c!-- truncate --\x3e\\n\\nIt helps with this migration by supporting:\\n\\n- Migration of Helm v2 configuration.\\n- Migration of Helm v2 releases.\\n- Clean up Helm v2 configuration, release data and Tiller deployment.\\n\\n## Setting up Helm v3\\n\\nAs we do not want to override Helm v2 CLI binary, we need to perform an additional step to ensure that both CLI versions can co-exist until we are ready to remove Helm v2 CLI and all it\'s related data:\\n\\nDownload latest Helm v3 release from [here](https://github.com/helm/helm/releases), rename the binary to `helm3` and store it in your path.\\n\\nWe are ready to use `helm3`:\\n\\n```\\n$ helm3 repo list\\nError: no repositories to show\\n```\\n\\nAs you see there are no repositories set as Helm v3 comes without `stable` repository setup by default, let\'s fix it up.\\n\\n## helm-2to3 plugin\\n\\n`helm-2to3` plugin will allow us to migrate and cleanup Helm v2 configuration and releases to Helm v3 in-place.\\n\\nInstalled Kubernetes objects will not be modified or removed.\\n\\n### Installing\\n\\nLet\'s install it:\\n\\n```\\n$ helm3 plugin install https://github.com/helm/helm-2to3\\nDownloading and installing helm-2to3 v0.2.0 ...\\nhttps://github.com/helm/helm-2to3/releases/download/v0.2.0/helm-2to3_0.2.0_darwin_amd64.tar.gz\\nInstalled plugin: 2to3\\n```\\n\\n```\\n$ helm3 plugin list\\nNAME \\tVERSION\\tDESCRIPTION\\n2to3 \\t0.2.0 \\tmigrate and cleanup Helm v2 configuration and releases in-place to Helm v3\\n```\\n\\n```\\n$ helm3 2to3\\nMigrate and Cleanup Helm v2 configuration and releases in-place to Helm v3\\n\\nUsage:\\n 2to3 [command]\\n\\nAvailable Commands:\\n
1cleanup cleanup Helm v2 configuration, release data and Tiller deployment\\n convert migrate Helm v2 release in-place to Helm v3\\n help Help about any command\\n move migrate Helm v2 configuration in-place to Helm v3\\n\\nFlags:\\n -h, --help help for 2to3\\n\\nUse \\"2to3 [command] --help\\" for more information about a command.\\n```\\n\\nAwesome.\\n\\n### Plugin features\\n\\nCurrently plugin supports:\\n\\n- Migration of Helm v2 configuration\\n- Migration of Helm v2 releases\\n- Clean up Helm v2 configuration, release data and Tiller deployment\\n\\n## Migrate Helm v2 configuration\\n\\nFirst we need to migrate Helm v2 config and data folders:\\n\\n```\\n$ helm3 2to3 move config -h\\nmigrate Helm v2 configuration in-place to Helm v3\\n\\nUsage:\\n 2to3 move config [flags]\\n\\nFlags:\\n --dry-run simulate a command\\n -h, --help help for move\\n```\\n\\nIt will migrate:\\n\\n- Chart starters\\n- Repositories\\n- Plugins\\n\\nThe safest way is to start with --dry-run flag:\\n\\n```\\n$ helm3 2to3 move config --dry-run\\n2019/11/14 14:54:04 NOTE: This is in dry-run mode, the following actions will not be executed.\\n2019/11/14 14:54:04 Run without --dry-run to take the actions described below:\\n2019/11/14 14:54:04\\n2019/11/14 14:54:04 WARNING: Helm v3 configuration maybe overwritten during this operation.\\n2019/11/14 14:54:04\\n[Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y\\n2019/11/14 14:54:12\\nHelm v2 configuration will be moved to Helm v3 configuration.\\n2019/11/14 14:54:12 [Helm 2] Home directory: /Users/rimas/.helm\\n2019/11/14 14:54:12 [Helm 3] Config directory: /Users/rimas/Library/Preferences/helm\\n2019/11/14 14:54:12 [Helm 3] Data directory: /Users/rimas/Library/helm\\n2019/11/14 14:54:12 [Helm 3] Create config folder \\"/Users/rimas/Library/Preferences/helm\\" .\\n2019/11/14 14:54:12 [Helm 2] repositories file \\"/Users/rimas/.helm/repository/repositories.yaml\\" will copy to [Helm 3] config folder \\"/Users/rimas/Library/Preferences/helm/repositories.yaml\\" .\\n2019/11/14 14:54:12 [Helm 3] Create data folder \\"/Users/rimas/Library/helm\\" .\\n2019/11/14 14:54:12 [Helm 2] plugins \\"/Users/rimas/.helm/plugins\\" will copy to [Helm 3] data folder \\"/Users/rimas/Library/helm/plugins\\" .\\n2019/11/14 14:54:12 [Helm 2] starters \\"/Users/rimas/.helm/starters\\" will copy to [Helm 3] data folder \\"/Users/rimas/Library/helm/starters\\" .\\n```\\n\\nCool, now let\'s do the actual migration:\\n\\n```\\n$ helm3 2to3 move config\\nWARNING: Helm v3 configuration maybe overwritten during this operation.\\n\\n[Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y\\n\\n2019/11/14 14:55:00 Helm v2 configuration will be moved to Helm v3 configuration.\\n2019/11/14 14:55:00 [Helm 2] Home directory: /Users/rimas/.helm\\n2019/11/14 14:55:00 [Helm 3] Config directory: /Users/rimas/Library/Preferences/helm\\n2019/11/14 14:55:00 [Helm 3] Data directory: /Users/rimas/Library/helm\\n2019/11/14 14:55:00 [Helm 3] Create config folder \\"/Users/rimas/Library/Preferences/helm\\" .\\n2019/11/14 14:55:00 [Helm 3] Config folder \\"/Users/rimas/Library/Preferences/helm\\" created.\\n2019/11/14 14:55:00 [Helm 2] repositories file \\"/Users/rimas/.helm/repository/repositories.yaml\\" will copy to [Helm 3] config folder \\"/Users/rimas/Library/Preferences/helm/repositories.yaml\\" .\\n2019/11/14 14:55:00 [Helm 2] repositories file \\"/Users/rimas/.helm/repository/repositories.yaml\\" copied successfully to [Helm 3] config folder \\"/Users/rimas/Library/Preferences/helm/repositories.yaml\\" .\\n2019/11/14 14:55:00 [Helm 3] Create data folder \\"/Users/rimas/Library/helm\\" .\\n2019/11/14 14:55:00 [Helm 3] data folder \\"/Users/rimas/Library/helm\\" created.\\n2019/11/14 14:55:00 [Helm 2] plugins \\"/Users/rimas/.helm/plugins\\" will copy to [Helm 3] data folder \\"/Users/rimas/Library/helm/plugins\\" .\\n2019/11/14 14:55:00 [Helm 2] plugins \\"/Users/rimas/.helm/plugins\\" copied successfully to [Helm 3] data folder \\"/Users/rimas/Library/helm/plugins\\" .\\n2019/11/14 14:55:00 [Helm 2] starters \\"/Users/rimas/.helm/starters\\" will c
1opy to [Helm 3] data folder \\"/Users/rimas/Library/helm/starters\\" .\\n2019/11/14 14:55:00 [Helm 2] starters \\"/Users/rimas/.helm/starters\\" copied successfully to [Helm 3] data folder \\"/Users/rimas/Library/helm/starters\\" .\\n2019/11/14 14:55:00 Helm v2 configuration was moved successfully to Helm v3 configuration.\\n```\\n\\nNow let\'s run `helm3 repo list` again:\\n\\n```\\n$ helm3 repo list\\nNAME \\tURL\\nstable \\thttps://kubernetes-charts.storage.googleapis.com\\njfrog \\thttps://charts.jfrog.io\\nrimusz \\thttps://charts.rimusz.net\\nbuildkite \\thttps://buildkite.github.io/charts\\njetstack \\thttps://charts.jetstack.io\\nodavid \\thttps://odavid.github.io/k8s-helm-charts\\nelastic \\thttps://helm.elastic.co\\nappscode \\thttps://charts.appscode.com/stable\\n\\n$ helm3 plugin list\\nNAME \\tVERSION\\tDESCRIPTION\\n2to3 \\t0.1.0 \\tmigrate Helm v2 configuration and releases in-place to Helm v3\\nedit \\t0.3.0 \\tEdit a release.\\ngcs \\t0.2.0 \\tProvides Google Cloud Storage protocol support.\\n \\t \\thttps://github.com/vigles...\\nlinter \\t0.1.1 \\tHelm plugin to find hardcoded passwords in values.yaml files\\nmonitor\\t0.3.0 \\tQuery at a given interval a Prometheus, ElasticSearch or Sentry instance...\\n```\\n\\nNice, now I can use the same Helm repositories and plugins which I have in Helm v2.\\n\\n**Note:** Please check that all Helm v2 plugins work fine with the Helm v3, and remove plugins that do not work.\\n\\nThe move config will create the Helm v3 `config` and `data` folders if they don\'t exist, and will override the `repositories.yaml` file if it does exist.\\n\\nThe plugin also supports non default Helm v2 `home` and Helm v3 `config` and `data` folders, an example of it\'s use:\\n\\n```\\n$ export HELM_V2_HOME=$HOME/.helm2\\n$ export HELM_V3_CONFIG=$HOME/.helm3\\n$ export HELM_V3_DATA=$PWD/.helm3\\n$ helm3 2to3 move config\\n```\\n\\n## Migrate Helm v2 releases\\n\\nNow we are ready to start migrating releases.\\n\\nLet\'s check available options:\\n\\n```\\n$ helm3 2to3 convert -h\\nmigrate Helm v2 release in-place to Helm v3\\n\\nUsage:\\n 2to3 convert [flags] RELEASE\\n\\nFlags:\\n --delete-v2-releases v2 release versions are deleted after migration. By default, the v2 release versions are retained\\n --dry-run simulate a command\\n -h, --help help for convert\\n -l, --label string label to select Tiller resources by (default \\"OWNER=TILLER\\")\\n -s, --release-storage string v2 release storage type/object. It can be \'secrets\' or \'configmaps\'. This is only used with the \'tiller-out-cluster\' flag (default \\"secrets\\")\\n --release-versions-max int limit the maximum number of versions converted per release. Use 0 for no limit (default 10)\\n -t, --tiller-ns string namespace of Tiller (default \\"kube-system\\")\\n --tiller-out-cluster when Tiller is not running in the cluster e.g. Tillerless\\n```\\n\\nNice, the plugin even supports the [Tillerless Helm v2](https://github.com/rimusz/helm-tiller).\\n\\nLet\'s check out for Helm v2 releases and pick one to test out the migration:\\n\\n```\\n$ helm list\\n\\nNAME \\tREVISION\\tUPDATED \\tSTATUS \\tCHART \\tAPP VERSION\\tNAMESPACE\\npostgres\\t1 \\tThu Nov 14 15:01:00 2019\\tDEPLOYED\\tpostgresql-7.1.0\\t11.5.0 \\tpostgres\\nredis \\t1 \\tThu Nov 14 15:02:12 2019\\tDEPLOYED\\tredis-9.5.4 \\t5.0.6 \\tredis\\n```\\n\\nThe safest way of course to start with `--dry-run` flag:\\n\\n```\\n$ helm3 2to3 convert --dry-run postgres\\n2019/11/14 15:03:17 NOTE: This is in dry-run mode, the following actions will not be executed.\\n2019/11/14 15:03:17 Run without --dry-run to take the actions described below:\\n2019/11/14 15:03:17\\n2019/11/14 15:03:17 Release \\"postgres\\" will be converted from Helm v2 to Helm v3.\\n2019/11/14 15:03:17 [Helm 3] Release \\"postgres\\" will be created.\\n2019/11/14 15:03:17 [Helm 3] ReleaseVersion \\"postgres.v1\\" will be created.\\n```\\n\\nNow, let\'s run the actual migration:\\n\\n```\\n$ helm3 2to3 convert postgres\\n2019/11/14 15:03:57 Release \\"postgres\\" will be converted from Helm v2 to Helm v3.\\n2019/11/14 15:03:57 [Helm 3] Release \\"postgres\\" will be created.\\n2019/11/14 15:03:57 [Helm 3] ReleaseVersion \\"postgres.v1\\" will be created.\\n2019/11/14 15:03:57 [Helm 3] ReleaseVersion \\"postgres.v1\\" created.\\n2019/11/14 15:03:57 [Helm 3] Release \\"postgres\\" created.\\n2019/11/14 15:03:57 Release \\"postgres\\" was converted successfully from Helm v2 to Helm v3.\\n2019/11/14 15:03:57 Note: The v2 release information still remains and should be removed to avoid conflicts with the migrated v3 release.\\n2019/11/14 15:03:57 v2 release information should only be removed using `helm 2to3` cleanup and when all releases have been migrated over.\\n```\\n\\nCheck out whether it was successful:\\n\\n```\\n$ helm list\\nNAME \\tREVISION\\tUPDATED \\tSTATUS \\tCHART \\tAPP VERSION\\tNAMESPACE\\npostgres\\t1 \\tThu Nov 14 15:01:00 2019\\tDEPLOYE
1D\\tpostgresql-7.1.0\\t11.5.0 \\tpostgres\\nredis \\t1 \\tThu Nov 14 15:02:12 2019\\tDEPLOYED\\tredis-9.5.4 \\t5.0.6 \\tredis\\n\\n$ helm3 list -n postgres\\nNAME \\tNAMESPACE\\tREVISION\\tUPDATED \\tSTATUS \\tCHART \\tAPP VERSION\\npostgres\\tpostgres \\t1 \\t2019-11-14 13:01:00.188487 +0000 UTC\\tdeployed\\tpostgresql-7.1.0\\t11.5.0\\n```\\n\\n**Note:** As we did not specify `--delete-v2-releases` flag Helm v2 `postgres` release information was left in-tact, it can be deleted with `helm3 2to3 cleanup` later on.\\n\\nWhen are you ready to move all your releases, you can automate it with running `helm list` in a loop and applying `helm3 2to3 convert RELEASE` for each Helm v2 release.\\n\\nIf you are using Tillerless Helm v2, just add `--tiller-out-cluster` to migrate the release:\\n\\n```\\n$ helm3 2to3 convert postgres --tiller-out-cluster\\n```\\n\\nVery cool and simple, right :-)\\n\\n## Clean up of Helm v2 data\\n\\nThe last step is cleaning up the old data. While this is not required, we strongly recommend it.\\n\\nLet\'s check available options:\\n\\n```\\n$ helm3 2to3 cleanup -h\\ncleanup Helm v2 configuration, release data and Tiller deployment\\n\\nUsage:\\n 2to3 cleanup [flags]\\n\\nFlags:\\n --config-cleanup if set, configuration cleanup performed\\n --dry-run simulate a command\\n -h, --help help for cleanup\\n -l, --label string label to select Tiller resources by (default \\"OWNER=TILLER\\")\\n --release-cleanup if set, release data cleanup performed\\n -s, --release-storage string v2 release storage type/object. It can be \'secrets\' or \'configmaps\'. This is only used with the \'tiller-out-cluster\' flag (default \\"secrets\\")\\n --tiller-cleanup if set, Tiller cleanup performed\\n -t, --tiller-ns string namespace of Tiller (default \\"kube-system\\")\\n --tiller-out-cluster when Tiller is not running in the cluster e.g. Tillerless\\n```\\n\\nIt will clean:\\n- Configuration (Helm home directory)\\n- v2 release data\\n- Tiller deployment\\n\\nAnd of course the safest way is to start with `--dry-run` flag:\\n\\n```\\n$ helm3 2to3 cleanup --dry-run\\n2019/11/14 15:06:59 NOTE: This is in dry-run mode, the following actions will not be executed.\\n2019/11/14 15:06:59 Run without --dry-run to take the actions described below:\\n2019/11/14 15:06:59\\nWARNING: \\"Helm v2 Configuration\\" \\"Release Data\\" \\"Release Data\\" will be removed.\\nThis will clean up all releases managed by Helm v2. It will not be possible to restore them if you haven\'t made a backup of the releases.\\nHelm v2 may not be usable afterwards.\\n\\n[Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: y\\n2019/11/14 15:07:01\\nHelm v2 data will be cleaned up.\\n2019/11/14 15:07:01 [Helm 2] Releases will be deleted.\\n2019/11/14 15:07:01 [Helm 2] ReleaseVersion \\"postgres.v1\\" will be deleted.\\n2019/11/14 15:07:01 [Helm 2] ReleaseVersion \\"redis.v1\\" will be deleted.\\n2019/11/14 15:07:01 [Helm 2] Home folder \\"/Users/rimasm/.helm\\" will be deleted.\\n```\\n\\nIt will show what releases going to be deleted, Tiller service to be removed from `kube-system` namespace and Helm v2 home folder will be deleted.\\n\\nWhen you are ready to clean up Hem v2 data, just run that command without `--dry-run` flag.\\n\\n**NOTE:** The `cleanup` command will remove the Helm v2 Configuration, Release Data and Tiller Deployment. It cleans up all releases managed by Helm v2. It will not be possible to restore them if you haven\'t made a backup of the releases. Helm v2 will not be usable afterwards.\\n\\nIf you are using Tillerless Helm v2, just add `--tiller-out-cluster` to clean up Helm v2 data.\\n\\nThe plugin also supports non default Helm v2 `home` data folder and Tiller releases `namespace`:\\n\\n```\\n$ export HELM_V2_HOME=$PWD/.helm2\\n$ helm 2to3 cleanup --tiller-ns some_namespace\\n```\\n\\n**Happy Helm v3 sailing**"},{"id":"helm-v3-beta","metadata":{"permalink":"/blog/helm-v3-beta","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-08-27-helm-v3-beta.md","source":"@site/blog/2019-08-27-helm-v3-beta.md","title":"Helm v3 Beta 1 Released","description":"Helm v3 development has hit a new milestone with the release of the first beta. This is an especially important milestone because it is the end of the effort to refactor Helm v3. The last of the intended breaking changes has landed. From this point on, Helm v3 is focused on bug fixes, stability, and preparing it for a stable release.","date":"2019-08-27T00:00:00.000Z","tags":[],"readingTime":3.79,"hasTruncateMarker":true,"authors":[{"name":"Matt Farina","page":{"permalink":"/blog/authors/mattfarina"},"socials":{"github":"https://github.com/mattfarina","linkedin":"https://www.linkedin.com/in/matthewfarina/","website":"https://mattfarina.com/"},"imageURL":"https://github.com/mattfarina.png","key":"mattfarina"}],"frontMatter":{"title":"Helm v3 Beta 1 Released","slug":"helm-v3-beta","authors":["mattfarina"],"date":"2019-08-27"},"unlisted":false,"prevItem":{"title":"How to migrate from Helm v2 to Helm v3","permalink":"/blog/migrate-from-helm-v2-to-helm-v3"},"nextItem":{"title":"Announcing get.helm.sh","permalink":"/blog/get-helm-sh"}},"content":"Helm v3 development has hit a new milestone with the release of the [first beta](https://github.com/helm/helm/releases/tag/v3.0.0-beta.
11). This is an especially important milestone because it is the end of the effort to refactor Helm v3. The last of the _intended_ breaking changes has landed. From this point on, Helm v3 is focused on bug fixes, stability, and preparing it for a stable release.\\n\\nIf you are interested in Helm v3 now is a great time to test it out. If you find issues please file an issue if one has not already been filed.\x3c!-- truncate --\x3e\\n\\n## Notable changes since Helm v2\\n\\n* Tiller has been removed. This simplifies the experience of using Helm. There is no more need to have cluster admin privileges or to install a Tiller in every namespace. With Tiller removed, Helm now uses the settings and access defined in the local kubeconfig file.\\n* A name is now required on install or you can use the `--generate-name` flag to have one automatically generated. This is a reverse of the Helm v2 behavior.\\n* The `helm init` command has been removed. It performed two primary functions. First, it installed Tiller. This is no longer needed. Second, it setup directories and repositories where Helm configuration lived. This is now automated. If the directory is not present it will be created.\\n* The Helm home directory used to be located off a users home directory. There is a standard known as the [XDG Base Directory Specification](https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) that describes a standard method to handle these directories. Helm now follows the XDG specification.\\n* The `stable` repository is no longer added by default. This repository will be deprecated during the life of Helm v3 and we are now moving to a distributed model of repositories that can be searched by the [Helm Hub](https://hub.helm.sh).\\n* The `helm search` command has been refactored to have sub-commands that can search the local repositories and the Helm Hub.\\n* Release names are now scoped to namespaces. In Helm v2 the names were scoped to the namespace Tiller was running in. When Tiller was running for an entire cluster the names were scoped to the cluster. Names are now scoped to the same namespace as the release.\\n* JSON schemas can now be imposed on chart values and bundled with the chart. The schemas can be used for validating chart values.\\n* A new API version of charts are available. This new `apiVersion` is `v2` and contains several changes including:\\n * Requirements are now listed in the `Chart.yaml` file instead of the `requirements.yaml` file.\\n * A `crd` directory has been added to charts for the placement of CRDs. These will be installed before the rendering of the templates is performed. Once the Kubernetes community has worked out more workflow details with CRDs more features can be added to Helm to support them.\\n* The `crd-install` hook has been removed and will not work for Helm v2 charts. A \\"legacy\\" plugin will be released by the Helm project to support v1 charts with the `crd-install` hook.\\n* Experimental feature gates are now supported. As new potential features are added to Helm they can be worked on as experiments and enabled using an environment variable.\\n* Pushing and pulling charts from OCI registries is now an experimental feature. The final details of this feature are being worked out with the OCI on the proper use of the API. To access this feature set the environment variable `HELM_EXPERIMENTAL_OCI=1` needs to be set.\\n* `helm serve` has been removed.\\n* Helm now supports library charts. These charts are not meant to be installed but can be depended on and referenced by other charts. These were inspired by the [common chart](https://github.com/helm/charts/tree/master/incubator/common) in the incubator repository.\\n* `helm test` received some major refactoring. This included the `test-success` hook\'s behavior coming in line with other hooks and the removal of the `test-failure` hook due to lack of use.\\n* Several CLI changes have happened for usability including:\\n * `helm inspect` is now `helm show`\\n * `helm fetch` is now `helm pull`\\n * `helm delete` is now `helm uninstall`\\n * Instead of using the `--purge` flag on `helm uninstall` the behavior is to use the `--keep-history` if you want to keep the history.\\n\\n## Helm v3 Next Steps\\n\\nThe next steps in the road to a Helm v3 stable release will be to focus on fixing bugs and stability. More beta releases or release candidates will follow before making a final `3.0.0` release."},{"id":"get-helm-sh","metadata":{"permalink":"/blog/get-helm-sh","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-06-10-get-helm-sh.md","source":"@site/blog/2019-06-10-get-helm-sh.md","title":"Announcing get.helm.sh","description":"The Helm Client has long been available to download from Google Cloud Storage at the bucket . This bucket in Google Cloud has been used by Helm since before Kubernetes w
1as part of the CNCF. The first release hosted on this bucket was Helm v2.0.0-alpha.5!","date":"2019-06-10T00:00:00.000Z","tags":[],"readingTime":4.64,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Announcing get.helm.sh","slug":"get-helm-sh","authors":["mattfisher"],"date":"2019-06-10"},"unlisted":false,"prevItem":{"title":"Helm v3 Beta 1 Released","permalink":"/blog/helm-v3-beta"},"nextItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 7: What\'s Next?","permalink":"/blog/helm-3-preview-pt7"}},"content":"The Helm Client has long been available to download from Google Cloud Storage at the bucket <https://kubernetes-helm.storage.googleapis.com>. This bucket in Google Cloud has been used by Helm since before Kubernetes was part of the CNCF. The first release hosted on this bucket was Helm v2.0.0-alpha.5!\\n\\nGoogle has long been gracious in providing funding for this location. Since Helm started using it, Helm (as part of Kubernetes) moved into the CNCF, and then moved out from under the Kubernetes umbrella, becoming a sister project to Kubernetes within the CNCF.\x3c!-- truncate --\x3e\\n\\nThe CNCF is in the process of taking over the infrastructure for Kubernetes. It was time for Helm to move from a location funded by Google to one funded by the CNCF. Google Cloud buckets cannot be transferred between projects, which meant we could not transfer the bucket over to a CNCF account. We needed to move to a new location as part of the move.\\n\\n## Where are we now?\\n\\nThe Helm project now publishes client downloads to <https://get.helm.sh>. All Helm releases from Helm v2.0.0-alpha.5 onwards are available for download, as well as the latest Helm 3 alpha.1 release.\\n\\nFor backwards compatibility concerns, new releases of Helm 2 will continue to be published at the old URL, however we strongly encourage users to migrate.\\n\\nGoing forward, this is the only location where you will find Helm 3; they are not being uploaded to the old storage bucket. Helm 3.0.0-alpha.1 builds are available there now.\\n\\n## What do I need to do?\\n\\nIf you\'re using the old URL in your CI pipeline, you can replace <https://kubernetes-helm.storage.googleapis.com/kubernetes-helm> with <https://get.helm.sh>.\\n\\nIf you\'re using [the get script](https://helm.sh/docs/using_helm/#from-script), it is now [pulling from the new URL](https://github.com/helm/helm/blob/2ca025d48222d6fa188653e2ca5eda6ed799145c/scripts/get#L114), so no changes on your end are required.\\n\\nAll the download URLs in our [GitHub releases](https://github.com/helm/helm/releases) have also been changed to use the new URL.\\n\\n## What\'s under the hood?\\n\\n`get.helm.sh` has three main components:\\n\\n1. [Azure Blob Storage](https://azure.microsoft.com/en-ca/services/storage/blobs/)\\n1. [Azure CDN](https://azure.microsoft.com/en-ca/services/cdn/)\\n1. The domain name `get.helm.sh`\\n\\nIn our release pipeline, Helm 2 and Helm 3 downloads are [uploaded to Azure Blob Storage](https://github.com/helm/helm/commit/022c8869bee37d02cf01507c11c6cfc6d58a1eca) (Helm 2 downloads are also [uploaded to Google Cloud Storage](https://github.com/helm/helm/commit/95775d0c60804b3d3674510e1f5
17a30ca8074ddd) for backwards compatibility). Azure CDN serves that content, which is fronted with a custom domain name.\\n\\n## Why the new location?\\n\\nAs part of the move, we started considering some new features the community has been asking for:\\n\\n### An official helm.sh URL\\n\\nDuring this transition, we wanted to ensure that we won\'t disrupt users a second time, asking them to change their deployment pipelines to point to a new location. We decided to place a URL we control in front of the storage provider. This way, we do not need to ask users to switch URLs again in the future. If the underlying storage provider needs to change at some point in the future, we can have the URL point at the new location without this level of disruption going forward.\\n\\n### Content delivery at the edge\\n\\n<https://get.helm.sh> is fronted by [Azure CDN](https://azure.microsoft.com/en-ca/services/cdn/), a Content Delivery Network that is globally available. This should provide faster downloads to those distributed around the world, not just to those located in the Eastern United States.\\n\\nIt also provides availability in regions that were previously unavailable, such as...\\n\\n### Availability in China\\n\\nChina is a large market for the CNCF, and therefore a large market for Helm. Google Cloud Storage is not accessible in China, so users in that region interested in using Helm have set up mirrors to work around this problem.\\n\\nThis is an area of concern in particular around adoption: As a user, I am now relying on an unofficial mirror to fetch my downloads, which comes with a certain level of risk I would not be subject to if I were fetching from the official release page like every other user.\\n\\nAzure CDN [can serve content to users in China](https://docs.microsoft.com/en-us/azure/cdn/cdn-china-delivery) using point-of-presence (POP) locations near China. With Helm downloads now available in China, we are seeing just how popular Helm is in that area thanks to...\\n\\n### Download metrics\\n\\nOne of the questions that keep popping up in our minds was how users are consuming Helm on a daily basis. The core maintainers were interested in answering the following questions:\\n\\n- what versions of Helm are being used?\\n- what regions of the world are using Helm today?\\n- How long does it take for the community to migrate over to a new version of Helm?\\n- How many users are downloading Helm 3 vs Helm 2?\\n\\nOur new CDN provides a rich set of metrics can provide answers to these questions.\\n\\nWhile these metrics are only available to core maintainers at this time, we are discussing how we can share these metrics with the community similar to <https://devstats.cncf.io/>.\\n\\n## Caveat: Tiller and Chart downloads\\n\\nPlease note that this change is only for the Helm client downloads. Tiller has not moved from Google Container Registry, and the stable and incubator Helm chart repositories are still hosted on Google Cloud.\\n\\n\\nIf you have any questions about this change, please let us know. More information on this change can be found under [issue #5663](https://github.com/helm/helm/issues/5663)."},{"id":"helm-3-preview-pt7","metadata":{"permalink":"/blog/helm-3-preview-pt7","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-05-13-helm-3-preview-pt7.md","source":"@site/blog/2019-05-13-helm-3-preview-pt7.md","title":"Helm 3 Preview: Charting Our Future \u2013 Part 7: What\'s Next?","description":"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.","date":"2019-05-13T00:00:00.000Z","tags":[],"readingTime":1.68,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 7: What\'s Next?","slug":"helm-3-preview-pt7","authors":["mattfisher"],"date":"2019-05-13"},"unlisted":false,"prevItem":{"title":"Announcing get.helm.sh","permalink":"/blog/get-helm-sh"},"nextItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 6: Introducing Library Charts","permalink":"/blog/helm-3-preview-pt6"}},"content":"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](https://helm.sh/blog/helm-3-preview-pt6/).\\n\\nHelm 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 O
1K; the idea of an alpha release is to test out an idea, gather feedback from early adopters, and validate those assumptions.\x3c!-- truncate --\x3e\\n\\nOnce the alpha has been released, we can start accepting patches from the community for Helm 3. We should have a stable foundation on which to build and accept new features, and users should feel empowered to open tickets and contribute fixes.\\n\\nIn this blog series, I have tried to highlight some of the big improvements coming to Helm 3, but this list is by no means exhaustive. The full plan for Helm 3 includes features such as improved upgrade strategies, deeper integrations with OCI registries, and applying JSON schemas against chart values for validation purposes. We\u2019re also taking a moment to clean up the codebase and updating parts that have languished over the last three years.\\n\\nIf you feel like a topic was missed, we\'d love to hear your thoughts!\\n\\nFeel free to join the discussion in [our Slack channels](https://kubernetes.slack.com):\\n\\n - `#helm-users` for questions and just to hang out with the community\\n - `#helm-dev` for discussing PRs, code, and bugs\\n\\nYou can also join and hang out in our weekly Public Developer Calls on Thursdays at 09:30PDT. The meeting is focused on discussing what the core maintainers and the community are working on, as well as any discussion topics for the week. Anyone is welcome to join this call and participate. The link is in the `#helm-dev` Slack channel.\\n\\nTTFN, ta ta for now!"},{"id":"helm-3-preview-pt6","metadata":{"permalink":"/blog/helm-3-preview-pt6","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-05-09-helm-3-preview-pt6.md","source":"@site/blog/2019-05-09-helm-3-preview-pt6.md","title":"Helm 3 Preview: Charting Our Future \u2013 Part 6: Introducing Library Charts","description":"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.","date":"2019-05-09T00:00:00.000Z","tags":[],"readingTime":1.01,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 6: Introducing Library Charts","slug":"helm-3-preview-pt6","authors":["mattfisher"],"date":"2019-05-09"},"unlisted":false,"prevItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 7: What\'s Next?","permalink":"/blog/helm-3-preview-pt7"},"nextItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 5: Changes to Chart Dependencies","permalink":"/blog/helm-3-preview-pt5"}},"content":"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](https://helm.sh/blog/helm-3-preview-pt5/).\\n\\nHelm 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. Globally scoped non-define content is simply ignored. This allows users to re-use and share snippets of code that can be re-used across many charts, avoiding redundancy and keeping charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\x3c!-- truncate --\x3e\\n\\nLibrary charts are declared in the `dependencies` directive in Chart.yaml, and are installed and managed like any other chart.\\n\\n```\\ndependencies:\\n - name: mylib\\n version: 1.x.x\\n repository: quay.io\\n```\\n\\nWe\'re very excited to see the use cases this feature opens up for chart developers, as well as any best practices that arise from consuming library charts.\\n\\nClick [here](https://helm.sh/blog/helm-3-preview-pt7/) to read the final part of our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks."},{"id":"helm-3-preview-pt5","metadata":{"permalink":"/blog/helm-3-preview-pt5","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-05-06-helm-3-preview-pt5.md","source":"@site/blog/2019-05-06-helm-3-preview-pt5.md","title":"Helm 3 Preview: Charting Our Future \u2013 Part 5: Changes to Chart Dependencies","description":"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.)","date":"2019-05-06T00:00:00.000Z","tags":[],"readingTime":1.34,"hasTruncateMarker":true,"authors":[{"name":"Matt Fis
1her","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 5: Changes to Chart Dependencies","slug":"helm-3-preview-pt5","authors":["mattfisher"],"date":"2019-05-06"},"unlisted":false,"prevItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 6: Introducing Library Charts","permalink":"/blog/helm-3-preview-pt6"},"nextItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 4: Release Management","permalink":"/blog/helm-3-preview-pt4"}},"content":"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](https://helm.sh/blog/helm-3-preview-pt4/).)\\n\\nCharts 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. One of the components that changed was the chart dependency management system.\x3c!-- truncate --\x3e\\n\\nThe Chart dependency management system moved from requirements.yaml and requirements.lock to Chart.yaml and Chart.lock, meaning that charts that relied on the `helm dependency` command will need some tweaking to work in Helm 3.\\n\\nLet\'s take a look at an example. Let\'s add a dependency to a chart in Helm 2 and then look at how that changed in Helm 3.\\n\\nIn Helm 2, this is how a requirements.yaml looked:\\n\\n```\\ndependencies:\\n- name: mariadb\\n version: 5.x.x\\n repository: https://kubernetes-charts.storage.googleapis.com/\\n condition: mariadb.enabled\\n tags:\\n - database\\n```\\n\\nIn Helm 3, the same dependency is expressed in your Chart.yaml:\\n\\n```\\ndependencies:\\n- name: mariadb\\n version: 5.x.x\\n repository: https://kubernetes-charts.storage.googleapis.com/\\n condition: mariadb.enabled\\n tags:\\n - database\\n```\\n\\nCharts are still downloaded and placed in the charts/ directory, so subcharts vendored into the charts/ directory will continue to work without modification.\\n\\nClick [here](https://helm.sh/blog/helm-3-preview-pt6/) to read the next blog where we introduce library charts in the next part of our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks."},{"id":"helm-3-preview-pt4","metadata":{"permalink":"/blog/helm-3-preview-pt4","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-05-02-helm-3-preview-pt4.md","source":"@site/blog/2019-05-02-helm-3-preview-pt4.md","title":"Helm 3 Preview: Charting Our Future \u2013 Part 4: Release Management","description":"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.","date":"2019-05-02T00:00:00.000Z","tags":[],"readingTime":2.25,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 4: Release Management","slug":"helm-3-preview-pt4","authors":["mattfisher"],"date":"2019-05-02"},"unlisted":false,"prevItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 5: Changes to Chart Dependencies","permalink":"/blog/helm-3-preview-pt5"},"nextItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 3: Chart Repositories","permalink":"/blog/helm-3-preview-pt3"}},"content":"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](https://helm.sh/blog/helm-3-preview-pt3/.).\\n\\nIn Helm 3, an application\'s state is tracked in-cluster by a pair of objects:\x3c!-- truncate --\x3e\\n\\n- The release object: represents an instance of an application\\n- The release version secret: represents an application\'s desired state at a particular instance of time (the release of a new version, for example)\\n\\nA `helm install` creates a release object and a release version secret. A `helm upgrade` requires an existing release object (which it may modify) and creates a new release version secret that c
1ontains the new values and rendered manifest.\\n\\nThe release object contains information about a release, where a release is a particular installation of a named chart and values. This object describes the top-level metadata about a release. The release object persists for the duration of an application lifecycle, and is the owner of all release version secrets, as well as of all objects that are directly created by the Helm chart.\\n\\nThe release version secret ties a release to a series of revisions (install, upgrades, rollbacks, delete).\\n\\nIn Helm 2, revisions were merely incremental. `helm install` created v1, a subsequent upgrade created v2, and so on. The release and release version secret were collapsed into a single object known as a revision. Revisions were stored in the same namespace as Tiller, meaning that each release name was \\"globally\\" namespaced; as a result, only one instance of a name could be used.\\n\\nFor Helm 3, a release has one or more release version secrets associated with it. The release object always describes the current release deployed to Kubernetes. Each release version secret describes just one version of that release. An upgrade operation, for example, will create a new release version secret, and then modify the release object to point to this new version. Rollback operations can use older release version secrets to roll back a release to a previous state.\\n\\nWith Tiller gone, Helm 3 stores release data in the same namespace as the release\'s destination. This change allows one to install a chart with the same release name in another namespace, and data is persisted between cluster upgrades/reboots in etcd. You can install Wordpress into namespace \\"foo\\" as well as namespace \\"bar\\", and both releases can be referred to as \\"wordpress\\".\\n\\nSpeaking of Charts...read the next blog [here](https://helm.sh/blog/helm-3-preview-pt5/) where we discuss changes to chart dependencies in our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks."},{"id":"helm-3-preview-pt3","metadata":{"permalink":"/blog/helm-3-preview-pt3","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-04-29-helm-3-preview-pt3.md","source":"@site/blog/2019-04-29-helm-3-preview-pt3.md","title":"Helm 3 Preview: Charting Our Future \u2013 Part 3: Chart Repositories","description":"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.)","date":"2019-04-29T00:00:00.000Z","tags":[],"readingTime":2.5,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 3: Chart Repositories","slug":"helm-3-preview-pt3","authors":["mattfisher"],"date":"2019-04-29"},"unlisted":false,"prevItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 4: Release Management","permalink":"/blog/helm-3-preview-pt4"},"nextItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 2: A Gentle Farewell to Tiller","permalink":"/blog/helm-3-preview-pt2"}},"content":"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](https://helm.sh/blog/helm-3-preview-pt2/).)\\n\\nAt 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.yaml file and some packaged charts.\x3c!-- truncate --\x3e\\n\\nWhile there are several benefits to the Chart Repository API meeting the most basic storage requirements, a few drawbacks have started to show:\\n\\n- Chart Repositories have a very hard time abstracting most of the security implementations required in a production environment. Having a standard API for authentication and authorization is very important in production scenarios.\\n- Helm\u2019s Chart provenance tools used for signing and verifying the integrity and origin of a chart are an optional piece of the Chart publishing process.\\n- In multi-tenant scenarios, the same Chart can be uploaded by another tenant, costing twice the storage cost to store the same content. Smarter chart repositories have been designed to handle this, but it\u2019s not a part of the formal specification.\\n- Using a single index file for search, metadata information, and fetching Charts has made it difficult or clunky to design around in secure multi-tenant implementations.\\n\\nDocker\u2019s [Distribution project](https://github.com/docker/distribution) (also known as Docker Registry v2) is the successor to the Docker Registry project, and is the de-facto toolset to pack, ship, store, and deliver Docker images. Many major cloud vendors have a product offering of the Distribution project, and with so many vendors offering the same product, the Distribution project has benefited from many years of hardening, security best practices, and battle-testing, making it one of the most successful unsung heroes of the open source world.\\n\\nBut did you know that the Distribution project was designed to distribute any form of content, not just container images?\\n\\nThanks to the efforts of the [Open Container Initiative (or OCI for short)](https://www.opencontainers.org/), Helm Charts can be hosted on any instance of Distribution. The work is experimental, with login support and other features considered \\"table stakes\\" for Helm 3 yet to be finished, but we\'re very excited to learn from previous discoveries that the OCI and Distribution teams have made over the years, learning through their mentorship and guidance on what it means to run a highly available service at scale.\\n\\nI wrote a more detailed deep-dive on some of the [upcoming changes to Helm Chart Repositories](https://blog.bacongobbler.com/post/2019-01-25-distributing-with-distribution/) if you\'d like to read more on the subject.\\n\\nYou can check out the next blog [here](https://helm.sh/blog/helm-3-preview-pt4/) where we discuss release management in the next part of our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks."},{"id":"helm-3-preview-pt2","metadata":{"permalink":"/blog/helm-3-preview-pt2","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-04-25-helm-3-preview-pt2.md","
1source":"@site/blog/2019-04-25-helm-3-preview-pt2.md","title":"Helm 3 Preview: Charting Our Future \u2013 Part 2: A Gentle Farewell to Tiller","description":"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.)","date":"2019-04-25T00:00:00.000Z","tags":[],"readingTime":1.89,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 2: A Gentle Farewell to Tiller","slug":"helm-3-preview-pt2","authors":["mattfisher"],"date":"2019-04-25"},"unlisted":false,"prevItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 3: Chart Repositories","permalink":"/blog/helm-3-preview-pt3"},"nextItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 1: A History of Helm","permalink":"/blog/helm-3-preview-pt1"}},"content":"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](https://helm.sh/blog/helm-3-preview-pt1/).)\\n\\nDuring 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.\x3c!-- truncate --\x3e\\n\\nWith role-based access controls (RBAC) enabled by default in Kubernetes 1.6, locking down Tiller for use in a production scenario became more difficult to manage. Due to the vast number of possible security policies, our stance was to provide a permissive default configuration. This allowed first-time users to start experimenting with Helm and Kubernetes without having to dive headfirst into the security controls. Unfortunately, this permissive configuration could grant a user a broad range of permissions they weren\'t intended to have. DevOps and
1SREs had to learn additional operational steps when installing Tiller into a multi-tenant cluster.\\n\\nAfter hearing how community members were using Helm in certain scenarios, we found that 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, we could simply fetch information from the Kubernetes API server, render the Charts client-side, and store a record of the installation in Kubernetes.\\n\\nTiller\u2019s primary goal could be accomplished without Tiller, so one of the first decisions we made regarding Helm 3 was to completely remove Tiller.\\n\\nWith Tiller gone, the security model for Helm is radically simplified. Helm 3 now supports all the modern security, identity, and authorization features of modern Kubernetes. Helm\'s permissions are evaluated using your [kubeconfig file](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). 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.\\n\\nRead the next blog post [here](https://helm.sh/blog/helm-3-preview-pt3/) where we discuss chart repositories in the next part of our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks."},{"id":"helm-3-preview-pt1","metadata":{"permalink":"/blog/helm-3-preview-pt1","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-04-22-helm-3-preview-pt1.md","source":"@site/blog/2019-04-22-helm-3-preview-pt1.md","title":"Helm 3 Preview: Charting Our Future \u2013 Part 1: A History of Helm","description":"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.","date":"2019-04-22T00:00:00.000Z","tags":[],"readingTime":4.41,"hasTruncateMarker":true,"authors":[{"name":"Matt Fisher","page":{"permalink":"/blog/authors/mattfisher"},"socials":{"github":"https://github.com/bacongobbler","linkedin":"https://www.linkedin.com/in/bacongobbler/","website":"https://blog.bacongobbler.com/"},"imageURL":"https://github.com/bacongobbler.png","key":"mattfisher"}],"frontMatter":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 1: A History of Helm","slug":"helm-3-preview-pt1","authors":["mattfisher"],"date":"2019-04-22"},"unlisted":false,"prevItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 2: A Gentle Farewell to Tiller","permalink":"/blog/helm-3-preview-pt2"},"nextItem":{"title":"Helm Summit EU 2019","permalink":"/blog/helm-summit-eu-2019"}},"content":"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](https://www.cncf.io/blog/2018/06/01/cncf-to-host-helm/) as an incubating project. Fast forward to today, and Helm 3 is nearing its first alpha release.\\n\\nIn 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.\x3c!-- truncate --\x3e\\n\\nIn order, I\'ll discuss:\\n\\n1. The history of the creation of Helm\\n2. A Gentle Farewell to Tiller\\n3. Chart Repositories\\n4. Release Management\\n5. Changes to Chart Dependencies\\n6. Library Charts\\n7. What\u2019s Next?\\n\\n### A History of Helm\\n\\nLet\'s get started. Part 1 of 7 of our *Helm 3 Preview: Charting Our Future* blog series is about the history of how Helm was created and evolved.\\n\\n#### Helm was Born\\n\\nHelm 1 began as an open source project created by Deis. We were a small startup company [acquired by Microsoft in the spring of 2017](https://blogs.microsoft.com/blog/2017/04/10/microsoft-acquire-deis-help-companies-innovate-containers/). Our other open source project - also called Deis - had a tool called [`deisctl`](https://github.com/deis/deis/tree/master/deisctl) that was used for (among other things) installing and operating the Deis platform on a [Fleet cluster](https://github.com/coreos/fleet). Fleet was one of the first \\"container orchestrator\\" platforms to exist at the time.\\n\\nIn mid-2015, we decided to shift gears, and the foundation of Deis (now re-named \\"Deis Workflow\\") moved from Fleet to Kubernetes. One of the first things we had to rewrite was the installation tool, `deisctl`. We used this tool to install and manage Deis Workflow on a Fleet cluster.\\n\\nModeled after package managers like Homebrew, apt, and yum, the focus of Helm 1 was to make it easy for users to package and install their applications on Kubernetes. We officially announced Helm in 2015 at the inaugural KubeCon in San Francisco.\\n\\nOur first attempt at Helm worked, but had its fair share of limitations. It took a set of Kubernetes manifests - sprinkled with generators as YAML front-matter - and loaded the generated results into Kubernetes.\\n\\nFor example, to substitute a field in a YAML file, one would add the following to a manifest:\\n\\n```\\n#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml\\n```\\n\\nMakes you really happy that template languages exist today, eh?\\n\\nFor many reasons, this early Kubernetes installer required a hard-coded list of manifest files and performed only a small fixed sequence of events. It was painful enough to use that the Deis Workflow R&D team was having a tough time replatforming their product around it, but the seed of an idea was there. Our first attempt was a very successful learning opportunity: we learned that we were passionate about building pragmatic solutions that solved real day-to-day problems for our users.\\n\\nLearning from our past mistakes, we started designing Helm 2.\\n\\n#### Designing Helm 2\\n\\nAs 2015 wound to a close, a team from Google reached out to the Helm team. They, too, had been working on a similar tool for Kubernetes. Deployment Manager for Kubernetes w
1as a port of an existing tool they used for Google Cloud Platform. Would we be interested, they asked, in spending a few days talking about similarities and differences?\\n\\nIn January 2016, the Helm and Deployment Manager teams sat down in Seattle to share some ideas. We walked out with a bold plan: merge the projects to create Helm 2. Along with Deis and Google, [SkippBox](https://github.com/skippbox) joined the development team, and we started work on Helm 2.\\n\\nOur goal was to maintain Helm\'s ease of use, but add the following:\\n\\n- Chart templates for customization\\n- In-cluster management for teams\\n- A first-class chart repository\\n- A stable and signable package format\\n- A strong commitment to semantic versioning and retaining backward compatibility version-to-version\\n\\nTo accomplish these goals, we added a second component to the Helm ecosystem. This in-cluster component was called Tiller, and it handled installing and managing Helm charts.\\n\\nSince the release of Helm 2 in 2016, Kubernetes added several major features. Role-Based Access Control (RBAC) was added and eventually replaced Attribute-Based Access Control (ABAC). Many new resource types were introduced (Deployments were still in beta at the time). Custom Resource Definitions (then called Third Party Resources, or TPRs) were invented. And most importantly, a set of best practices emerged.\\n\\nThroughout all of these changes, Helm continued to serve the needs of Kubernetes users. After 3 years and many new feature additions, it became a good idea to introduce some major changes to the code base so that Helm would continue to meet the needs of this evolving ecosystem.\\n\\nThis brings us to Helm 3 -- check out our next blog post [here](https://helm.sh/blog/helm-3-preview-pt2/) where we discuss the fate of Tiller in our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks."},{"id":"helm-summit-eu-2019","metadata":{"permalink":"/blog/helm-summit-eu-2019","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-04-18-helm-summit-eu-2019.md","source":"@site/blog/2019-04-18-helm-summit-eu-2019.md","title":"Helm Summit EU 2019","description":"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 existing users.","date":"2019-04-18T00:00:00.000Z","tags":[],"readingTime":0.9,"hasTruncateMarker":true,"authors":[{"name":"Karen Chu","page":{"permalink":"/blog/authors/karenchu"},"socials":{"github":"https://github.com/karenhchu","linkedin":"https://www.linkedin.com/in/karenhchu/"},"imageURL":"https://github.com/karenhchu.png","key":"karenchu"}],"frontMatter":{"title":"Helm Summit EU 2019","slug":"helm-summit-eu-2019","authors":["karenchu"],"date":"2019-04-18"},"unlisted":false,"prevItem":{"title":"Helm 3 Preview: Charting Our Future \u2013 Part 1: A History of Helm","permalink":"/blog/helm-3-preview-pt1"},"nextItem":{"title":"ChartMuseum Vulnerability: Authorization Bypass [CVE-2019-1000009]","permalink":"/blog/chartmuseum-security-notice-2019"}},"content":"We\'re beyond excited to share that [Helm Summit EU 2019](https://events.linuxfoundation.org/events/helm-summit-2019/) is now official (h/t to [CNCF](https://cncf.io/))! 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 existing users.\x3c!-- truncate --\x3e\\n\\nInterested in... \\n\\n* Registering? Sign up [here](https://events.linuxfoundation.org/events/helm-summit-2019/register/) before Aug 27 for Early Bird pricing of $250. Prices will go up to the Standard pricing of $300 thereafter. \\n\\n* CFPs? Submit a proposal for a lighting talk, presentation, or tutorial before the Friday May 31 deadline. Click [here](https://events.linuxfoundation.org/events/helm-summit-2019/program/call-for-proposals/) for details. \\n\\n* Sponsoring? Sponsorships are now open and in limited quantity. Please reach out to [email protected] for the sponsorship prospectus. \\n\\nIn the mean time, make sure to follow us on [Twitter](https://twitter.com/HelmPack) for the most up-to-date news on #HelmSummit!"},{"id":"chartmuseum-security-notice-2019","metadata":{"permalink":"/blog/chartmuseum-security-notice-2019","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-01-14-chartmuseum-security-notice.md","source":"@site/blog/2019-01-14-chartmuseum-security-notice.md","title":"ChartMuseum Vulnerability: Authorization Bypass [CVE-2019-1000009]","description":"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.","date":"2019-01-14T00:00:00.000Z","tags":[],"readingTime":1.48,"hasTruncateMarker":true,"authors":[],"frontMatter":{"title":"ChartMuseum Vulnerability: Authorization Bypass [CVE-2019-1000009]","slug":"chartmuseum-security-notice-2019","date":"2019-01-14"},"unlisted":false,"prevItem":{"title":"Helm Summit EU 2019","permalink":"/blog/helm-summit-eu-2019"},"nextItem":{"title":"Helm Vulnerability: Client Unpacking Chart that Contains Malicious Content [CVE-2019-1000008]","permalink":"/blog/helm-security-notice-2019"}},"content":"Security researcher Bernard Wagner of [Entersekt](https://www.entersekt.com/) 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.\\n\\nWhen 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.\\n\x3c!-- truncate --\x3e\\n\\nAdditionally, 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.\\n\\nWe are unaware of any public exploits caused by this issue.\\n\\n## Details\\n\\nWhen a chart archive is uploaded the name of the chart, as listed in the `Chart.yaml` file, is used when creating the path location to save the file. The name is joined with the directory or object storage prefix path. The chart name was not sanitized or validated. This allowed directory traversal characters, such as `../..`, to be used in the name and affect the directory the archive file is saved within.\\n\\nWhen the Helm client creates a chart archive, via the `helm package` command, it validates that the chart name and encapsulating directory match. It will not generate a chart archive with directory traversal characters.\\n\\n## Fix\\n\\nUpdate to ChartMuseum >= 0.8.1\\n\\nTo prevent this from happening, ChartMuseum now checks the name of the chart to make sure there are no directory traversal characters in the name before using it to save the archive. If the name contains directory traversal characters the API will return a _400 Bad Request_ response and message to signify the name issue."},{"id":"helm-security-notice-2019","metadata":{"permalink":"/blog/helm-security-notice-2019","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2019-01-14-helm-security-notice.md","source":"@site/blog/2019-01-14-helm-security-notice.md","title":"Helm Vulnerability: Client Unpacking Chart that Contains Malicious Content [CVE-2019-1000008]","description":"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.","date":"2019-01-14T00:00:00.000Z","tags":[],"readingTime":1.79,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"}],"frontMatter":{"title":"Helm Vulnerability: Client Unpacking Chart that Contains Malicious Content [CVE-2019-1000008]","slug":"helm-security-notice-2019","authors":["mattbutcher"],"date":"2019-01-14"},"unlisted":false,"prevItem":{"title":"ChartMuseum Vulnerability: Authorization Bypass [CVE-2019-1000009]","permalink":"/blog/chartmuseum-security-notice-2019"},"nextItem":{"title":"Introducing the Helm Hub","permalink":"/blog/intro-helm-hub"}},"content":"Security researcher Bernard Wagner of [Entersekt](https://www.entersekt.com/) 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.\\n\\nA specially crafted chart may be able to unpack content into locations on the filesystem outside of the chart\u2019s path, potentially overwriting existing files.\\n\x3c!-- truncate --\x3e\\n\\nNo version of Tiller is known to be impacted. This is a client-only issue.\\n\\nThe following Helm commands may unsafely unpack malformed charts onto a local folder: `helm fetch --untar` and `helm lint some.tgz`.\\n\\n\\
1nWe are unaware of any public exploits caused by this issue.\\n\\n## Details\\n\\nDuring unpacking operations, file names were not checked to see if they contained references to parent directories. Normally, this does not impact Helm\u2019s operation because file names are only used as in-memory names. However, two operations were found to export files directly to disk without sanitizing the file names. The `helm lint` command may unpack a tar archive into a temporary directory, and `helm fetch --untar` will unpack an archive into a user-supplied directory. In both cases, not all file names were correctly sanitized.\\n\\nNo Tiller version is impacted. This vulnerability does not render clusters vulnerable to attack. Tiller does not store unpacked charts. All charts are loaded in-memory, and paths are resolved as string names, not as locations on a file system.\\n\\n## Workarounds\\n\\nUnpack charts with the appropriate `tar` command, and do not use the `--untar` flag on `helm fetch`. Do not run `helm lint` on tars. Unpack them manually and run `helm lint` on the unpacked directory.\\n\\n## Fix\\n\\nUpdate to Helm >= 2.12.2.\\n\\nAs of Helm 2.12.2, the unpacking operation disallows paths that could be used to store files outside of the present working directory. This is considered a bug fix, rather than a breaking change, because there is no way to produce such malformed packages from within Helm or from standard chart-building tools.\\n\\nFrom Helm 2.12.2 onward, charts that contain files that are not relative to the current working directory will fail to load, even when loaded into memory."},{"id":"intro-helm-hub","metadata":{"permalink":"/blog/intro-helm-hub","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2018-12-11-helm-hub.md","source":"@site/blog/2018-12-11-helm-hub.md","title":"Introducing the Helm Hub","description":"Helm was designed with many distributed repositories in mind. Like Homebrew Taps and Debian APT repositories, Helm has the ability to add and work with many repositories. While the Helm stable and incubator repositories have been front and center from the beginning it was never our intent for these to be the only public repositories.","date":"2018-12-11T00:00:00.000Z","tags":[],"readingTime":1.35,"hasTruncateMarker":true,"authors":[],"frontMatter":{"title":"Introducing the Helm Hub","slug":"intro-helm-hub","date":"2018-12-11"},"unlisted":false,"prevItem":{"title":"Helm Vulnerability: Client Unpacking Chart that Contains Malicious Content [CVE-2019-1000008]","permalink":"/blog/helm-security-notice-2019"},"nextItem":{"title":"Introducing the Helm Org Maintainers","permalink":"/blog/intro-helm-org-maintainers"}},"content":"Helm was designed with many distributed repositories in mind. Like Homebrew Taps and Debian APT repositories, Helm has the ability to add and work with many repositories. While the Helm [stable and incubator repositories](https://github.com/helm/charts) have been front and center from the beginning it was never our intent for these to be the only public repositories.\\n\\nWith this in mind, we are delighted to announce the launch of the [Helm Hub](https://hub.helm.sh). This hub provides a means for you to find charts hosted in many distributed repositories hosted by numerous people and organizations. \x3c!-- truncate --\x3e\\n\\n\\n\\nHelm repositories can be hosted in many ways including as GitHub or GitLab pages, in object storage, using [Chartmuseum](https://github.com/helm/chartmuseum), and via a service provider.\\n\\nIf you have a chart repository you would like listed please head over to the [hub repository on GitHub](https://github.com/helm/hub) and follow the directions. The process is as simple as a pull request.\\n\\nThe Helm Hub is powered by [Monocular](https://github.com/helm/monocular), one of the projects that has long been a part of Helm. This was originally crafted by Bitnami and Deis, now part of Microsoft. As the Helm Hub grows in complexity, Monocular will need to grow in its ability to handle many repositories and charts. This is an area where UI and UX designers looking to be part of the Helm and [CNCF](https://cncf.io) community can contribute and make a difference.\\n\\nWe look forward to the Helm Hub ushering in a new phase of chart development and sharing."},{"id":"intro-helm-org-maintainers","metadata":{"permalink":"/blog/intro-helm-org-maintainers","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2018-10-04-helm-org-maintainers.md","source":"@site/blog/2018-10-04-helm-org-maintainers.md","title":"Introducing the Helm Org Maintainers","description":"The first major action under the new Helm governance was to elect a set of Helm Org Maintainers. In the initial election we were looking to select 7 people to represent Helm core, charts, and other projects under the Helm umbrella. The election is now complete and I would like to introduce the first set of Org Maintainers.","date":"2018-10-04T00:00:00.000Z","tags":[],"readingTime":0.98,"hasTruncateMarker":true,"authors":[],"frontMatter":{"title":"Introducing the Helm Org Maintainers","slug":"intro-helm-org-maintainers","date":"2018-10-04"},"unlisted":false,"prevItem":{"title":"Introducing the Helm Hub","permalink":"/blog/intro-helm-hub"},"nextItem":{"title":"Using the Community Chart Testing Tools Yourself","permalink":"/blog/chart-testing-intro"}},"content":"The first major action under the [new Helm governance](https://www.helm.sh/blog/new-gov-and-elections/index.html) was to elect a set of [Helm Org Maintainers](https://github.com/helm/community/blob/52161625acabf4187ae052f4e5fdd36daea91684/governance/governance.md#helm-org-maintainers
1). In the initial election we were looking to select 7 people to represent Helm core, charts, and other projects under the Helm umbrella. The election is now complete and I would like to introduce the first set of Org Maintainers. \x3c!-- truncate --\x3e\\n\\nIn alphabetical order, by first name, they are:\\n\\n* Adam Reese (adamreese)\\n* Adnan Abdulhussein (prydonius)\\n* Josh Dolitsky (jdolitsky)\\n* Matt Butcher (technosophos)\\n* Matt Farina (mattfarina)\\n* Matt Fisher (bacongobbler)\\n* Reinhard N\xe4gele (unguiculus)\\n* Scott Rigby (scottrigby)\\n* Vic Iglesias (viglesiasce)\\n\\nThanks to everyone who ran. Helm is off to a great start under the CNCF and this is another step in our journey.\\n\\n## What Do Org Maintainers Do?\\n\\nOrg Maintainers are responsible for maintaining the vision, mission, values, and scope of the broader Helm project. This includes the Helm client, the charts repository, ChartMuseum, and Monocular. While the org maintainers are not responsible for the technical direction of each individual project, they take on the higher level task of keeping the organization unified."},{"id":"chart-testing-intro","metadata":{"permalink":"/blog/chart-testing-intro","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2018-09-25-chart-testing-intro.md","source":"@site/blog/2018-09-25-chart-testing-intro.md","title":"Using the Community Chart Testing Tools Yourself","description":"The Helm community charts, available as the stable and incubator repositories, have long had testing. That testing has grown and improved a significant amount in the past year; from Helm linting and testing if an application runs in a cluster to now include YAML linting, some validation on maintainers, Chart.yaml schema validation, tests on chart version increments, and more.","date":"2018-09-25T00:00:00.000Z","tags":[],"readingTime":4.09,"hasTruncateMarker":true,"authors":[],"frontMatter":{"title":"Using the Community Chart Testing Tools Yourself","slug":"chart-testing-intro","date":"2018-09-25"},"unlisted":false,"prevItem":{"title":"Introducing the Helm Org Maintainers","permalink":"/blog/intro-helm-org-maintainers"},"nextItem":{"title":"New Governance And Elections","permalink":"/blog/new-gov-and-elections"}},"content":"The Helm community charts, [available as the stable and incubator repositories](https://github.com/helm/charts), have long had testing. That testing has grown and improved a significant amount in the past year; from Helm linting and testing if an application runs in a cluster to now include YAML linting, some validation on maintainers, `Chart.yaml` schema validation, tests on chart version increments, and more. \x3c!-- truncate --\x3e\\n\\nThese testing tools are useful for more than the community charts. They could be used in development workflows, in other testing systems, and for private charts. To make the testing more accessible we (mostly [Reinhard N\xe4gele](https://github.com/unguiculus/)) refactored the tools into a container image that can be run outside of the community charts testing infrastructure.\\n\\nThis new image is now available as the [Chart Testing project](https://github.com/helm/chart-testing). This project is built and maintained by the Helm Charts Maintainers, powers the community chart testing process, and is being used elsewhere.\\n\\n## Example: Locally on Mac\\n\\nOne of the easiest ways to take a look at it is to try it out locally. To aid with that, one of the [examples provided by the project shows you how to use it with Docker for Mac](https://github.com/helm/chart-testing/tree/main/examples/docker-for-mac) with the [charts repository](https://github.com/helm/charts). An easy way to try it out is to make a change to a chart and run the following command from the root of the charts directory:\\n\\n $ /path/to/chart-testing/examples/docker-for-mac/my_test.sh\\n\\nTo illustrate this I added a tag in the `Chart.yaml` file of the mariadb chart without incrementing the chart version. Running the test produced the following output:\\n\\n Cluster \\"docker-for-desktop-cluster\\" set.\\n Cluster \\"docker-for-desktop-cluster\\" set.\\n Switched to context \\"docker-for-desktop\\".\\n\\n --------------------------------------------------------------------------------\\n Environment:\\n REMOTE=k8s\\n TARGET_BRANCH=master\\n CHART_DIRS=stable incubator\\n EXCLUDED_CHARTS=common\\n CHART_REPOS=incubator=https://kubernetes-charts-incubator.storage.googleapis.com/\\n TIMEOUT=600\\n LINT_CONF=/testing/etc/lintconf.yaml\\n CHART_YAML_SCHEMA=/testing/etc/chart_schema.yaml\\n VALIDATE_MAINTAINERS=true\\n GITHUB_INSTANCE=https://github.com\\n CHECK_VERSION_INCREMENT=true\\n --------------------------------------------------------------------------------\\n\\n Charts to be installed and tested: stable/mariadb\\n Initializing Helm client...\\n Creating /root/.helm\\n Creating /root/.helm/repository\\n Creating /root/.helm/repository/cache\\n Creating /root/.helm/repository/local\\n Creating /root/.helm/plugins\\n Creating /root/.helm/starters\\n Creating /root/.helm/cache/archive\\n Creating /root/.helm/repository/repositories.yaml\\n Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com\\n Adding local repo with URL: http://127.0.0.1:8879/charts\\n $HELM_HOME has been configured at /root/.helm.\\n Not installing Tiller due to \'client-only\' flag having been set\\n Happy Helming!\\n \\"incubator\\" has been added to your repositories\\n\\
1n --------------------------------------------------------------------------------\\n Processing chart \'stable/mariadb\'...\\n --------------------------------------------------------------------------------\\n\\n Validating chart \'stable/mariadb\'...\\n Checking chart \'stable/mariadb\' for a version bump...\\n Chart version on k8s/master : 5.0.3\\n New chart version: 5.0.3\\n ERROR: Chart version not ok. Needs a version bump.\\n Linting \'stable/mariadb/Chart.yaml\'...\\n Linting \'stable/mariadb/values.yaml\'...\\n Validating Chart.yaml\\n Validating /workdir/stable/mariadb/Chart.yaml...\\n Validation success! \u{1F44D}\\n Validating maintainers\\n Verifying maintainer \'bitnami-bot\'...\\n ERROR: Chart validation failed.\\n Building dependencies for chart \'stable/mariadb\'...\\n No requirements found in stable/mariadb/charts.\\n Chart does not provide test values. Using defaults...\\n Linting chart \'stable/mariadb\'...\\n ==> Linting stable/mariadb\\n Lint OK\\n\\n 1 chart(s) linted, no failures\\n --------------------------------------------------------------------------------\\n \u2716\uFE0E stable/mariadb\\n --------------------------------------------------------------------------------\\n\\nYou\'ll notice the chart failed to pass testing because the version was not incremented.\\n\\n## Configurable\\n\\nWhile the testing image contains defaults, it is configurable so it can be used without any association to the community charts setup. The [configuration is handled via environment variables which are documented in the README.md file](https://github.com/helm/chart-testing/blob/main/README.md#configuration).\\n\\nFor example, if you wanted to skip checking for a version increment on the chart for every change you can set `CHECK_VERSION_INCREMENT` to `false`. This will skip that check and is useful for cases where every change to a chart is not released.\\n\\n## Example: Using It with CircleCI\\n\\nLinting, without trying to operate the chart, is easy to incorporate into a workflow. The following is a simple example CircleCI configuration to do so:\\n\\n version: 2\\n jobs:\\n lint-charts:\\n docker:\\n - image: quay.io/helmpack/chart-testing:v1.1.0\\n steps:\\n - checkout\\n - run:\\n name: lint\\n command: |\\n chart_test.sh --config .testenv --no-install\\n workflows:\\n version: 2\\n lint:\\n jobs:\\n - lint-charts\\n\\nIn this case the environment variables for the configuration are stored in a file name `.testenv`. This file holds the environment variables and is sourced into the environment. The following is an example from the community charts:\\n\\n # The name of the Git remote\\n REMOTE=k8s\\n\\n # The name of the Git target branch\\n TARGET_BRANCH=master\\n\\n # Chart directories separated by a space\\n CHART_DIRS=(\\n stable\\n incubator\\n )\\n\\n # Charts that should be skipped\\n EXCLUDED_CHARTS=(\\n common\\n )\\n\\n # Additional chart repos to add (<name>=<url>), separated by a space\\n CHART_REPOS=(\\n incubator=https://kubernetes-charts-incubator.storage.googleapis.com/\\n )\\n\\n TIMEOUT=600\\n\\n## Try It in Your Workflow\\n\\nThis toolchain, wrapped in a container image, is meant to be used in a wide variety of workflows. Please take it for a spin, give it a try, use it in your workflows, and provide feedback."},{"id":"new-gov-and-elections","metadata":{"permalink":"/blog/new-gov-and-elections","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2018-09-07-new-gov-and-elections.md","source":"@site/blog/2018-09-07-new-gov-and-elections.md","title":"New Governance And Elections","description":"Being a top level incubating CNCF project requires having a governance structure to ensure that there is a publicly documented process for making decisions regarding the project and the community. While Helm was under Kubernetes, we relied on Kubernetes governance. As part of the transition to CNCF, the Helm project is required to have its own governance structure. To handle this we set up a provisional governance with a goal of creating a long term one. After a few months we are happy to announce that the new governance structure has been written and approved.","date":"2018-09-07T00:00:00.000Z","tags":[],"readingTime":2.38,"hasTruncateMarker":true,"authors":[],"frontMatter":{"title":"New Governance And Ele
1ctions","slug":"new-gov-and-elections","date":"2018-09-07"},"unlisted":false,"prevItem":{"title":"Using the Community Chart Testing Tools Yourself","permalink":"/blog/chart-testing-intro"},"nextItem":{"title":"Helm Moves To DCO","permalink":"/blog/helm-dco"}},"content":"Being a top level incubating CNCF project requires having a governance structure to ensure that there is a publicly documented process for making decisions regarding the project and the community. While Helm was under Kubernetes, we relied on Kubernetes governance. As part of the transition to CNCF, the Helm project is required to have its own governance structure. To handle this we set up a [provisional governance](https://github.com/helm/community/blob/aa0586011786dfbc3993e7edd959a841241c96e3/governance/provisional-governance.md) with a goal of creating a long term one. After a few months we are happy to announce that the new governance structure has been written and approved. \x3c!-- truncate --\x3e\\n\\nThe gist of the new governance is that it organizes those responsible into a couple groups (org and project maintainers), spells out their responsibilities, and provides for decision making processes. You can read all the details in the [governance doc (here)](https://github.com/helm/community/blob/main/governance/governance.md).\\n\\n## Two Types of Maintainers\\n\\nThe new governance has two types of maintainers. **Project Maintainers** are those who maintain the code, documentation, websites, and so forth. There are currently several groups of maintainers for Helm core, Charts, ChartMuseum, Monocular, and Web/Docs. These are the same people who have been maintaining this work.\\n\\nThe second type of maintainer is the **Helm Org Maintainer**. These individuals are responsible for elements such as the scope, vision, brand, code of conduct, owning security issues, finances, and other aspects of this nature.\\n\\n## Next Step: Selecting Helm Org Maintainers\\n\\nThe next step in the process is to select the initial Helm Org Maintainers. To handle this selection we are using the documented process in the governance. _Anyone who has contributed to the Helm GitHub organization can nominate one of the Project Maintainers to be a Helm Org Maintainer._ This includes the Project Maintainers of Helm core, Charts, ChartMuseum, etc. The nomination period will be open for three weeks (closing on 9/28 at 12pm PT). We wanted Helm Org Maintainers to be project maintainers so that they have shown they are vested in Helm by their actions.\\n\\nAfter that the project maintainers will vote. How that vote works will depend on the number of nominated individuals, who they work for as no one company can have a majority of members, and some other rules.\\n\\nTo provide for a diverse representation from the projects in the initial selection of Helm Org Maintainers the selected folks will include 3 Representatives from the Helm core project, 2 Representative from the Charts project, and 2 Representatives representing another Helm project. The initial election will create a total of 7 Helm Org Maintainers. The length of their terms is open ended and how changes happen is documented in the governance.\\n\\nIf you have questions about the process, or how to nominate someone, please use the [Helm mailing list](https://lists.cncf.io/g/cncf-helm)."},{"id":"helm-dco","metadata":{"permalink":"/blog/helm-dco","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2018-08-27-helm-switch-dco.md","source":"@site/blog/2018-08-27-helm-switch-dco.md","title":"Helm Moves To DCO","description":"When Helm was part of the Kubernetes project it, like the rest of Kubernetes, used the CNCF Contributor License Agreement (CLA). This served Helm well for years. But, most of the CNCF projects use a Developers Certificate of Origin (DCO) instead of a CLA. The exceptions are Kubernetes and gRPC. Upon Helm becoming a CNCF project itself we were asked if we wanted to move Helm to a DCO. After some careful consideration and a little research, the Helm maintainers voted to move to a DCO.","date":"2018-08-27T00:00:00.000Z","tags":[],"readingTime":4.49,"hasTruncateMarker":true,"authors":[],"frontMatter":{"title":"Helm Moves To DCO","slug":"helm-dco","date":"2018-08-27"}
1,"unlisted":false,"prevItem":{"title":"New Governance And Elections","permalink":"/blog/new-gov-and-elections"},"nextItem":{"title":"Helm Emeritus Maintainer Rimas Mocevicius","permalink":"/blog/helm-emeritus-maintainer-rimas-mocevicius"}},"content":"When Helm was part of the Kubernetes project it, like the rest of Kubernetes, used the [CNCF Contributor License Agreement (CLA)](https://github.com/cncf/cla). This served Helm well for years. But, most of the CNCF projects use a [Developers Certificate of Origin (DCO)](https://developercertificate.org/) instead of a CLA. The exceptions are Kubernetes and gRPC. Upon Helm becoming a CNCF project itself we were asked if we wanted to move Helm to a DCO. After some careful consideration and a little research, the Helm maintainers voted to move to a DCO. \x3c!-- truncate --\x3e\\n## What Does This Solve? Why Switch?\\n\\nMaking a change like this should have a good reason and we have one. It is often easier to get started contributing under a DCO than a CLA.\\n\\nWhen one is developing software for a company they need to have the company sign the Corporate CLA prior to submitting contributions. That means there is a step after the business decides to contribute where legal documents need to be signed and exchanged. Once this is done there are steps to associate people with those legal documents. All of this takes time. In some companies this process can take weeks or longer.\\n\\nWe wanted to make it simpler to contribute.\\n\\n## What Is A DCO?\\n\\nA DCO is lightweight way for a developer to certify that they wrote or otherwise have the right to submit c
1ode or documentation to a project. The way a developer does this is by adding a `Signed-off-by` line to a commit. When they do this they are agreeing to the DCO.\\n\\nThe full text of the DCO can be found at https://developercertificate.org. It reads:\\n\\n> Developer Certificate of Origin\\n> Version 1.1\\n>\\n> Copyright (C) 2004, 2006 The Linux Foundation and its contributors.\\n> 1 Letterman Drive\\n> Suite D4700\\n> San Francisco, CA, 94129\\n> \\n> Everyone is permitted to copy and distribute verbatim copies of this\\n> license document, but changing it is not allowed.\\n> \\n> \\n> Developer\'s Certificate of Origin 1.1\\n> \\n> By making a contribution to this project, I certify that:\\n> \\n> (a) The contribution was created in whole or in part by me and I\\n> have the right to submit it under the open source license\\n> indicated in the file; or\\n> \\n> (b) The contribution is based upon previous work that, to the best\\n> of my knowledge, is covered under an appropriate open source\\n> license and I have the right under that license to submit that\\n> work with modifications, whether created in whole or in part\\n> by me, under the same open source license (unless I am\\n> permitted to submit under a different license), as indicated\\n> in the file; or\\n> \\n> (c) The contribution was provided directly to me by some other\\n> person who certified (a), (b) or (c) and I have not modified\\n> it.\\n> \\n> (d) I understand and agree that this project and the contribution\\n> are public and that a record of the contribution (including all\\n> personal information I submit with it, including my sign-off) is\\n> maintained indefinitely and may be redistributed consistent with\\n> this project or the open source license(s) involved.\\n\\nAn example signed commit message might look like:\\n\\n> An example commit message\\n> \\n> Signed-off-by: Some Developer <[email protected]>\\n\\nGit has a flag that can sign a commit for you. An example using it is:\\n\\n```\\n$ git commit -s -m \'An example commit message\'\\n```\\n\\nIn the past, once someone wanted to contribute they needed to go through the CLA process first. Now they just need to signoff on the commit.\\n\\n## FAQs\\n\\n### What About Existing Pull Requests Under The CLA\\n\\nIf a pull request was previously submitted under the CLA we will still honor those. All new contributions will need to be under the DCO and any pull requests that are updated will need to conform to the DCO prior to merging.\\n\\n### What About The Other Elements Of A CLA\\n\\nThe CNCF CLA has provisions for some areas other than right to contribute the code. For example, there is an explicit patent grant and that the contribution is \\"on an \\"AS IS\\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND\\". The CNCF views elements like these as already being covered elsewhere. For example, through the code contributions being under the Apache 2 license which has patent grant and warranty clauses.\\n\\n### What About Commits With Multiple Contributors\\n\\nIf more than one person works on something it\'s possible for more than one person to sign off on it. For example,\\n\\n> An example commit message\\n> \\n> Signed-off-by: Some Developer <[email protected]>\\n> Signed-off-by: Another Developer <[email protected]>\\n\\n### If I Contribute As An Employee Does My Employer Need To Sign Anything\\n\\nNope. The DCO assumes you are authorized to submit the code. This is what makes the contributor experience simpler for many people.\\n\\n### What If I Forget To Sign-off On A Commit\\n\\nThere is a DCO check, similar to the previous CLA check, that will cause the status of the pull requests to be listed as failed. This will remind everyone that the commit was not signed off.\\n\\nTo update the last commit message with a sign off you can use the command:\\n\\n```\\n$ git commit --amend -s\\n```\\n\\nThe `-s` flag is short for `--signoff`.\\n\\nIf you need to amend older commit message the process is a little more detailed. [GitHub has a writeup detailing on changing commit messages](https://help.github.com/articles/changing-a-commit-message/) that deals with numerous different cases."},{"id":"helm-emeritus-maintainer-rimas-mocevicius","metadata":{"permalink":"/blog/helm-emeritus-maintainer-rimas-mocevicius","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2018-07-24-helm-emeritus-rimus.md","source":"@site/blog/2018-07-24-helm-emeritus-rimus.md","title":"Helm Emeritus Maintainer Rimas Mocevicius","description":"Rimas Mocevicius (rimusz) has become the fourth Helm Emeritus Maintainer. Rimas is one of the three original founders of Helm. Author of CoreOS Essentials (Packt, 2016) and creator of Kube Solo, Rimas is a long-time member of the Kubernetes ecosystem. Rimas was an active contributor on Helm Classic, and has been a leading voice in the community ever since.","date":"2018-07-24T00:00:00.000Z","tags":[],"readingTime":0.44,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"}],"frontMatter":{"title":"Helm Emeritus Maintainer Rimas Mocevicius","slug":"helm-emeritus-maintainer-rimas-mocevicius","authors":["mattbutcher"],"date":"2018-07-24"},"unlisted":false,"prevItem":{"title":"Helm Moves To DCO","permalink":"/blog/helm-dco"},"nextItem":{"title":"Bringing Helm Home","permalink":"/blog/bringing-helm-home"}},"content":"Rimas Mocevicius ([rimusz](https://github.com/rimusz)) has become the fourth Helm Emeritus Maintainer.\x3c!-- truncate --\x3e Rimas is one of the three original founders of Helm. Author of [CoreOS Essentials](https://rimusz.net/coreos-essential-book/) (Packt, 2016) and creator of [Kube Solo](https://github.com/TheNewNormal/kube-solo-osx), Rimas is a long-time member of the Kubernetes ecosystem. Rimas was an active contributor on Helm Classic, and has been a leading voice in the community ever since.\\n\\nCheck out Rimas\' latest blog post on [Tillerless Helm](https://rimusz.net/tillerless-helm)."},{"id":"bringing-helm-home","metadata":{"permalink":"/blog/bringing-helm-home","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2018-07-23-bring-helm-home.md","source":"@site/blog/2018-07-23-bring-helm-home.md","title":"Bringing Helm Home","description":"Earlier this summer, we announced that Helm joined the CNCF as an official incubating project. Part of that transition involves moving the Helm project out of the Kubernetes GitHub org and into its org. We\u2019re excited to announce that we\u2019ve completed that process. As of last week, we have moved the Helm code repository to https://github.com/helm/helm.","date":"2018-07-23T00:00:00.000Z","tags":[],"readingTime":1.61,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"}],"frontMatter":{"title":"Bringing Helm Home","slug":"bringing-helm-home","authors":["mattbutcher"],"date":"2018-07-23"},"unlisted":false,"prevItem":{"title":"Helm Emeritus Maintainer Rimas Mocevicius","permalink":"/blog/helm-emeritus-maintainer-rimas-mocevicius"},"nextItem":{"title":"Helm Enters the CNCF","permalink":"/blog/helm-enters-the-cncf"}},"content":"Earlier this summer, we announced that [Helm joined the CNCF](https://www.cncf.io/blog/2018/06/01/cncf-to-host-helm/) as an official incubating project. Part of that transition involves moving the Helm project out of the Kubernetes GitHub org and into its org. We\u2019re excited to announce that we\u2019ve completed that process. As of last week, we have moved the Helm code repository to [https://github.com/helm/helm](https://github.com/helm/helm). \x3c!-- truncate --\x3e\\n\\nFun fact: This is the same GitHub repository where the Helm project first started. When we started Helm in 2015, we created the Helm organization in GitHub. But thanks to the enthusiastic supp
1ort of the Kubernetes community, we migrated the entire codebase into the Kubernetes org in 2016. As a separate CNCF project with its own vibrant and growing ecosystem, it makes sense to once again have Helm back home in its own GitHub org.\\n\\nSince the first beta release of Helm 2.0, we have pledged to keep Helm stable for users and developers alike. Before moving Helm into its new GitHub home, we tested to make sure that this would not break existing builds or existing tooling. Thanks to GitHub\u2019s excellent support for repository moving, we believe we have maintained our stability promise.\\n\\nAlong with the main Helm source code repo, we have moved a few other Helm related repositories including [Charts](https://github.com/helm/charts), [Monocular](https://github.com/helm/monocular), [Community](https://github.com/helm/community), [ChartMuseum](https://github.com/helm/chartmuseum), and other Helm projects all under the official CNCF Helm GitHub org. This means the community can find all Helm related items under one GitHub org.\\n\\nThis isn\u2019t our only big news since joining CNCF. Helm 3 is now underway, as developers begin adding new features. And soon we will announce a minor process change that will simplify the process of becoming a Helm contributor as we switch from requiring a CLA to a DCO."},{"id":"helm-enters-the-cncf","metadata":{"permalink":"/blog/helm-enters-the-cncf","editUrl":"https://github.com/helm/helm-www/blob/main/blog/2018-06-01-cncf.md","source":"@site/blog/2018-06-01-cncf.md","title":"Helm Enters the CNCF","description":"Today we are happy to announce that Helm has become an official top-level CNCF project, joining the ranks of Prometheus, Linkerd, OpenTracing, and others. Helm will enter the CNCF as an incubating project as we continue to work on the next-generation Helm 3 cloud-native package manager.","date":"2018-06-01T00:00:00.000Z","tags":[],"readingTime":1.34,"hasTruncateMarker":true,"authors":[{"name":"Matt Butcher","page":{"permalink":"/blog/authors/mattbutcher"},"socials":{"github":"https://github.com/technosophos","linkedin":"https://www.linkedin.com/in/mattbutcher/","website":"http://technosophos.com/"},"imageURL":"https://github.com/technosophos.png","key":"mattbutcher"}],"frontMatter":{"title":"Helm Enters the CNCF","slug":"helm-enters-the-cncf","authors":["mattbutcher"],"date":"2018-06-01"},"unlisted":false,"prevItem":{"title":"Bringing Helm Home","permalink":"/blog/bringing-helm-home"}},"content":"Today we are happy to announce that Helm has become an official top-level [CNCF](https://www.cncf.io/) project, joining the ranks of Prometheus, Linkerd, OpenTracing, and others. Helm will enter the CNCF as an incubating project as we continue to work on the next-generation Helm 3 cloud-native package manager. \x3c!-- truncate --\x3e\\n\\nWe are grateful to the Helm community, which has diligently contributed to the core Helm project, to the official charts repository, Monocular, to Chart Museum, and to other Helm-related projects. As a CNCF project, we look forward to expanding the Helm ecosystem. Over the coming months, we will be re-organizing as we ease our way out of the Kubernetes org and into CNCF.\\n\\nHelm began as an internal hackathon project at Deis, and we made our first public release at the original KubeCon. Now, only a few short years later, the Helm ecosystem has seen 3,500 contributors spanning 566 companies. We have made more than 50 releases, and see over 50,000 downloads per month. And last February, we had the [inaugural Helm Summit](https://www.youtube.com/playlist?list=PLVt9l4b66d5EjjJ_VBe_5tEiJrAGLsDb-), where 179 developers, operators, and SREs gathered in Portland, Oregon to talk about the future of the project.\\n\\nThank you for making the Helm community a welcoming place where people from all skill levels can participate in this emerging cloud-native landscape! We are excited to improve Helm as the package manager for the cloud-native landscape.\\n\\nWe would like to conclude with special thanks to Brian Grant for sponsoring the CNCF proposal, and Matt Farina for writing the proposal and guiding it through the process."}]}}')}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.