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)
Not good to close an issue without explaining the way to fix 😃 Let me do it instead then.
First, some information for newbies. In Kubernetes there are:
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:
kubectl [--namespace kube-system] get serviceaccount
create if not:kubectl [--namespace kube-system] create serviceaccount tiller
kubectl [--namespace kube-system] get clusterrole
you can check role content via:kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
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
kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml
I suspect that your output will not have settings “serviceAccount” and “serviceAccountName”:
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:Yes. Something like that.
https://docs.helm.sh/using_helm/#role-based-access-control
New URL for anyone looking: https://helm.sh/docs/rbac/#role-based-access-control
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:
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:
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…
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.
@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!