During the Helm 2 development cycle, we introduced Tiller. 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.
With 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 SREs had to learn additional
operational steps when installing Tiller into a multi-tenant cluster.
After 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.
Tiller’s primary goal could be accomplished without Tiller, so one of the first decisions we made regarding Helm 3 was
to completely remove Tiller.
With 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.
### Release Names are now scoped to the Namespace
With the removal of Tiller, the information about each release had to go somewhere. In Helm 2, this was stored in the
same namespace as Tiller. In practice, this meant that once a name was used by a release, no other release could use
that same name, even if it was deployed in a different namespace.
In Helm 3, release information about a particular release is now stored in the same namespace as the release itself.
This means that users can now `helm install wordpress stable/wordpress` in two separate namespaces, and each can be
referred with `helm list` by changing the current namespace context.
Charts are still downloaded and placed in the charts/ directory, so subcharts vendored into the charts/ directory will continue to work without modification.
### Name (or --generate-name) is now required on install
In Helm 2, if no name was provided, an auto-generated name would be given. In production, this proved to be more of a
nuisance than a helpful feature. In Helm 3, Helm will throw an error if no name is provided with `helm install`.
For those who still wish to have a name auto-generated for you, you can use the `--generate-name` flag to create one for
you.
### Pushing Charts to OCI Registries
At a high level, a Chart Repository is a location where Charts can be stored and shared. The Helm client packs and ships
Helm Charts to a Chart Repository. Simply put, a Chart Repository is a basic HTTP server that houses an index.yaml file
and some packaged charts.
While there are several benefits to the Chart Repository API meeting the most basic storage requirements, a few
drawbacks have started to show:
- 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.
- Helm’s Chart provenance tools used for signing and verifying the integrity and origin of a chart are an optional piece of the Chart publishing process.
- 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’s not a part of the formal specification.
- 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.
Docker’s Distribution project (also known as Docker Registry v2) is the successor to the Docker Registry project. 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.
Please have a look at `helm help chart` and `helm help registry` for more information on how to package a chart and
### Why aren't there Debian/Fedora/... native packages of Helm?
We'd love to provide these or point you toward a trusted provider. If you're
interested in helping, we'd love it. This is how the Homebrew formula was
started.
### Why do you provide a `curl ...|bash` script?
There is a script in our repository (`scripts/get`) that can be executed as
a `curl ..|bash` script. The transfers are all protected by HTTPS, and the script
does some auditing of the packages it fetches. However, the script has all the
usual dangers of any shell script.
We provide it because it is useful, but we suggest that users carefully read the
script first. What we'd really like, though, are better packaged releases of
Helm.
### How do I put the Helm client files somewhere other than ~/.helm?
Set the `$HELM_HOME` environment variable, and then run `helm init`:
```console
export HELM_HOME=/some/path
helm init --client-only
```
Note that if you have existing repositories, you will need to re-add them
with `helm repo add...`.
## Uninstalling
### I want to delete my local Helm. Where are all its files?
Along with the `helm` binary, Helm stores some files in `$HELM_HOME`, which is
located by default in `~/.helm`.
## Troubleshooting
### On GKE (Google Container Engine) I get "No SSH tunnels currently open"
```
Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"?
```
Another variation of the error message is:
```
Unable to connect to the server: x509: certificate signed by unknown authority
```
The issue is that your local Kubernetes config file must have the correct credentials.
When you create a cluster on GKE, it will give you credentials, including SSL
certificates and certificate authorities. These need to be stored in a Kubernetes
config file (Default: `~/.kube/config` so that `kubectl` and `helm` can access
them.
### Why do I get a `unsupported protocol scheme ""` error when trying to pull a chart from my custom repo?**
