helm: Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in the namespace "kube-system"

I’m trying to follow INSTALLING TILLER, yet running into following error:

$ helm list
Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in the namespace "kube-system"
$

Output of helm version:

$ helm version
Client: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
$ 

Output of kubectl version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:31:33Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
$ 

Cloud Provider/Platform (AKS, GKE, Minikube etc.):

bare metal, linux

possibly related, I’m also trying to access Tiller and Role-Based Access Control, yet getting 404.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 5
  • Comments: 17 (4 by maintainers)

Most upvoted comments

Not good to close an issue without explaining the way to fix 😃 Let me do it instead then.

Error: configmaps is forbidden: User “system:serviceaccount:kube-system:default” cannot list

First, some information for newbies. In Kubernetes there are:

  • Account - something like your ID. Example: john
  • Role - some group in the project permitted to do something. Examples: cluster-admin, it-support, …
  • Binding - joining Account to Role. “John in it-support” - is a binding.

Thus, in our message above, we see that our Tiller acts as account “default” registered at namespace “kube-system”. Most likely you didn’t bind him to a sufficient role.

Now back to the problem. How do we track it:

  • check if you have specific account for tiller. Usually it has same name - “tiller”: kubectl [--namespace kube-system] get serviceaccount create if not: kubectl [--namespace kube-system] create serviceaccount tiller
  • check if you have role or clusterrole (cluster role is “better” for newbies - it is cluster-wide unlike namespace-wide role). If this is not a production, you can use highly privileged role “cluster-admin”: kubectl [--namespace kube-system] get clusterrole you can check role content via: kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • check if account “tiller” in first clause has a binding to clusterrole “cluster-admin” that you deem sufficient: kubectl [--namespace kube-system] get clusterrolebinding if it is hard to figure out based on names, you can simply create new: kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • finally, when you have the account, the role and the binding between them, you can check if you really act as this account: kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

I suspect that your output will not have settings “serviceAccount” and “serviceAccountName”:

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
...

if yes, than add an account you want tiller to use: kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}' (if you use PowerShell, then check below for post from @snpdev) Now you repeat previous check command and see the difference:

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: tiller                     <-- new line
serviceAccountName: tiller          <-- new line
terminationGracePeriodSeconds: 30
...

Yes. Something like that.

Guys, please take it easy. We’re all software developers, share same values in life. We have much more in common than you even can imaging. Let’s respect each other please.

@marckhouzam inappropriate ? In no shape or form have I disrespected anybody with my comment. I simply stated the facts from my perspective. This comment was directly mentioned @bacongobbler not everybody else who put in there 2 cents. I appreciate @bacongobbler for pasting the link on a holiday. The original question states he was having issues and needed guidance not a link. Guys if you can’t take constructive criticism then don’t post anything on these threads. We are all software developers trying to become better and provide better information.

and 2 moths and 1/2 your explanation is still being helpful thank you very much for taking the time out of your busy schedule to be detailed and helpful. @m-abramovich unlike @bacongobbler

@m-abramovich solution worked for me.

Note: if using Powershell, the command is:

kubectl --namespace kube-system patch deploy tiller-deploy -p '{\"spec\":{\"template\":{\"spec\":{\"serviceAccount\":\"tiller\"}}}}'

Wow. I don’t even remember answering to this thread… Been a while.

@marckhouzam’s assumption here is correct: the issue was opened on Christmas Day. I happened to be with my family that day, but I saw this quick question from the OP:

possibly related, I’m also trying to access Tiller and Role-Based Access Control, yet getting 404.

So I figured I’d shoot a quick answer with the correct link and get back to celebrating Christmas. The next day, the OP closed the issue, so I assumed no further follow-up was required.

It really upsets me to think my comment was assumed as being terse or unhelpful. I wasn’t trying to solve the issue; I was merely providing context while the OP tries to find the solution themselves over the holiday season.

Thank you @m-abramovich and @snpdev for following up and providing answers to OP’s issue.

I apologize for not proving my answer with greater details as I sort of hinted the answer in my question and then @bacongobbler confirmed my answer, followed by great comment by @m-abramovich

I really do appreciate everyone’s help and/or input and I will try to do better job next time, I promise!

and again, I’m sorry for causing this( I really didn’t think it’d get to that…

and 2 moths and 1/2 your explanation is still being helpful thank you very much for taking the time out of your busy schedule to be detailed and helpful. @m-abramovich unlike @bacongobbler

The person who closed this issue was the person who opened it. Clearly they felt the issue was resolved.

Furthermore, the original description asked for the proper link to the role-based access control documentation, which was provided without closing the issue.

Finally, @bacongobbler took the time to provide the requested information on December 25th, which for many is an important holiday. I’m sorry @iamaverrick but I find your comment quite inappropriate.

@m-abramovich Thank you! Your detailed walk through helped me get through this issue. I very much appreciate the time you took to write your response up.

My two cents: when following https://helm.sh/docs/intro/quickstart/, there’s no mention of RBAC and the instructions there lead to a non-working installation of tiller. A google search then leads to this issue here.

Perhaps it can be reopened as “enhance quickstart guide so that it warns newbies about this pitfall”?

@pohly Patrick, I believe this is not relevant anymore. Helm v3 doesn’t use Tiller. So, maybe, all that is worthless now.

This explanation is great! Thanks!