Unclear error message when doing a Helm install with RBAC enabled

[ata18]

Setup

Helm 2.6.0
Kubernetes 1.7 with RBAC enabled

Steps to reproduce

With RBAC enabled and no cluster role bindings created for tiller if we try to do a helm install, it fails with the following error which doesn't make much sense.

helm install stable/memcached --namespace memcached-ns
Error: no available release name found

When I create the necessary cluster role bindings, it works fine.

kubectl create clusterrolebinding tiller --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

helm install stable/memcached --namespace memcached-ns

NAME:   gangly-puffin
LAST DEPLOYED: Fri Aug 25 13:59:41 2017
NAMESPACE: memcached-ns
STATUS: DEPLOYED

[seh]

Presumably the error that Tiller had no permission to read ConfigMap objects via the Kubernetes API gets buried here.

As a side note, please be careful granting Tiller "cluster-admin" permission unless you're sure that cluster users who should not have such permission can't run helm and get it to find your Tiller pod. If they have the ability to list pods in the "kube-system" namespace (using your example deployment) and can use the "create" verb against the "pods/portforward" resource, they can get helm to control Tiller.

[walidshaari]

@seh what should be the minimal rules given to a helm role?

[seh]

The question isn't clear. What do you mean here by a "[H]elm role?" For Tiller's service account, or for someone else to be able to use the helm command-line tool to control Tiller?

[walidshaari]

no not tiller user, but role to give to helm users to search/install charts, wondering if privileges (rules) needed are safe to give to ordinary users "developers" users of the clusters.

…

On 8 September 2017 at 01:50, Steven E. Harris ***@***.***> wrote: The question isn't clear. What do you mean here by a "[H]elm role?" For Tiller's service account, or for someone else to be able to use the *helm* command-line tool to control Tiller? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2861 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABrQ9DALaZFqJUL4juwb4Jv95RICnZQ8ks5sgHM0gaJpZM4PDMMK> .

[seh]

These privileges are not safe to give to ordinary users, as you're promoting them to have many of the same privileges as an administrator, by way of them installing Helm charts that do what they need, or by way of them deleting Helm charts that others need.

Here's a Role manifest that shows what it takes for a user to be able to run helm against Tiller, assuming that Tiller is running in a pod under a Deployment (or, more specifically, a ReplicaSet) with a name that we can't predict:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
 name: discover-tiller
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list
- apiGroups:
  - ""
  resources:
  - pods/portforward
  verbs:
  - create

Create that role in the namespace in which you run Tiller. Here we'll call that namespace "ns-with-tiller-running," but feel free to choose a better name.

Note that we have to grant the ability to "create" a "pods/portforward" resource to all pods in the namespace because we don't know the name of Tiller's pod. If we did know the name, we could restrict that latter grant with a "resourceNames" rule entry, nominating only Tiller's pod.

You'd create that "discover-tiller" role in the namespace where Tiller is running, and create a RoleBinding in the same namespace to allow other subjects to find (and, hence, use) Tiller. (Here those subjects are in the group "editors" over in namespace "user-of-tiller".)

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: discover-tiller
roleRef:
  kind: Role
  name: discover-tiller
  apiGroup: rbac.authorization.k8s.io
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: editors
  namespace: user-of-tiller

For Tiller to operate on a given namespace, you can allow it to do so as follows. Here we allow Tiller's service account over in "ns-with-tiller-running" to manipulate objects in this namespace within the permissions of the bootstrap "edit" ClusterRole:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: tiller-edit
roleRef:
- apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: ServiceAccount
  name: tiller
  namespace: ns-with-tiller-running

By the way, if Tiller is storing its release records in ConfigMap objects, these are the permissions that Tiller's service account needs in its own namespace:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
 name: tiller-bookkeeping
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch

It won't use all of those verbs, but it's traditional to grant all of them together to an "owner" of a set of objects, so that we don't constrai how it goes about managing them.

[bacongobbler]

So #2962 (and @seh's answer above) answers the question about how to grant tiller access to create resources in a RBAC-enabled environment, so that should solve the docs question. We should still keep this ticket open to fix the issue where Helm returns an unclear error message when RBAC is enabled:

Error: no available release name found

[vhosakot]

Per #2224 (comment), the following commands resolved the error for me:

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

[jhoblitt]

I believe #3664 is essentially a dup of this issue

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[prageethw]

@seh thanks mate, your answer resolved tiller issue, I had no idea how to resolve it otherwise :)

[prageethw]

after all, as it stands below is the most viable solution with rbac enabled to me it seems.
https://gist.github.com/venezia/69e9bd25d79fec9834fe1c5b589d4206

[jayjlawrence]

I'm arriving here as a new gcloud/kubernetes user now adopting helm to help me get this stuff running. As I worked through the intro steps when I encountered this issue:

$ helm install stable/mysql
Error: no available release name found

I concluded that there was something wrong with finding stable/mysql. I would assume release is referring to mysql, the latest would be implied. So helm cannot find the latest release of stable/mysql for me. This sends me searching in the wrong direction.

Would something like "Error: no available means to control your cluster" be more appropriate? Plus hint like "check context and access control" which then could direct the user through the steps to confirm/repair his RBAC. And as for the finer points of RBAC etc -- as a noob I don't know, I just learned the term 15 minutes ago.

HTH

[bacongobbler]

Closing as the original issue raised by the OP was likely fixed in Helm 3. Please comment if this issue persists with Helm 3. Thanks!