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

https://docs.helm.sh/using_helm/#role-based-access-control

New URL for anyone looking: https://helm.sh/docs/rbac/#role-based-access-control

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.

@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\"}}}}'

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

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.

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.

@iamaverrick To provide a link to documentation is not uncommon when responding to an issue. This is not being unhelpful but a belief in our documentation which we as a community invest a lot of time on. if the documentation is inadequate then the person usually responds and this then give the responder the opportunity to provide more context. It also makes us aware that the doc needs improvement. Without interaction or feedback like this from users, the docs will not improve.

In the long run better documentation helps people more than having to raise issues for non related bugs or features.

On another level, for @bacongobbler to respond during the holiday season at all is quite impressive. Remember we are all people trying to do our best.

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.

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...

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"?

There is "Deciding what security configurations to apply to your installation, if any" under prerequisites, but as I was just trying it out on a throwaway cluster, the "if any" implied to me that as I don't care, I don't need to do anything.

Even if I had noticed that I need to do something, there's no link to instructions.

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.

@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.

This explanation is great! Thanks!