Helm: system:default not sufficient for helm, but works for kubectl

I fixed my issue - it was related to running things in kube-system. I don't know why my helm client (using same kubeconfig as my kubectl) couldn't access that NS, but I'm thinking we should print a warning when installing helm w/o a custom namespace.

@jayunit100 can you please explain how you got around this issue exactly? by deploying tiller-deploy in a different namespace? I'm using an OpenShift cluster and it deployed tiller-deploy in the kube-system namespace automatically.

@shraderdm

• http://jayunit100.blogspot.com/2017/07/helm-on.html I wrote up my notes here. tiller-namespace= can switch the namespace for you, but likely,

• if you're seeing failed to list erros, then the real issue you are hitting is that, by default, your cluster doesn't add a service account to pods which allows the tiller pods to list stuff.

• so the real trick is that you have to make sure there is a corresponding service account, which grants privileges that helm needs i.e.

roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

• One final note: The above svc account might be a superset of whats actually needed for helm, but it works, and was shared w/ me by the heptio folks, as its necessary on some clusters, depending on the default service accounts that pods get launched with /

@jayunit100 Sorry for the delay in getting to this issue. Would you consider your initial proposal still valid after solving the issue? It looks really good and I'd love to keep it open for discussion so we can implement it down the road

@jayunit100 nice blog post! I had solved it similarly, but there were a few other issues I had to solve in OpenShift as well. It basically came down to the same issue though, rbac blocking my access, and needing to add cluster-admin to the service account that deploys the tiller. I also deployed it in a different namespace and had to remove some nodeselectors, etc. (although I was already past that point when I posted my question here). I hope your proposal goes through though, to allow others to more easily solve this issue in the future. :)

Yeah definetely I hope so to. I'm happy to help implement as well ; might need some pointers on how to get ramped up on helm dev/testing . I'll check the docs first

Sounds good @jayunit100. Let us know if you need any help.

Per jayunit100 's advice, add role cluster-admin to serviceaccount kube-system:default works for me, below is the cmd.

kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

Why are you running Tiller with the "default" service account?

this sounds related and will likely be closed via the proposed documentation in https://github.com/kubernetes/helm/issues/2962.

@seh I am running helm with the defaults, as the instructions said to do a "helm init" and what I got is this situation, it installs tiller-deploy-xxxx into the kube-system namespace and I'm assuming that by default it tries to use the default service account too.

I believe we can close this now that #3094 was merged and is available to view at https://docs.helm.sh/using_helm/#role-based-access-control. I'm going to close this but please let us know if there's something else we missed. Thanks!

Shouldn't the initialisation of helm automatically setup this account, since it cannot operate without it, it appears strange that I also need to setup the service account also, since its a prerequisite for it to function correctly?

The default service account should already be there by... puts on shades... default. 😎

Is this not the case? I haven't heard of a case before where the default service account does not exist in kube-system.

For background information, Helm (and therefore tiller) have no idea what a service account is. They just happen to need one to talk to the kubernetes API server. There are multiple different use cases in RBAC environments, some of which can be seen in the docs. There are also other authentication policies such as Attribute-based access control (ABAC) that do not tie into RBAC roles at all. With that in mind, we decided not to bake RBAC support directly into helm init and pigeon-hole users into one scenario.

ok, so it needs to be part of the installation instructions, at the same location where helm init is described, since this actually is a make or break issue for the installation and not an advanced option, its literally the default thing most of us will have to do if we are running on kubernetes 1.8 with a default setup.

and its not described anywhere, except a separate page, which leads me to believe its a side issue, or an advanced topic, but this is really critical to getting it working in kubernetes default RBAC mode

@leejian0612 Thanks a lot, i was stuck for ~ 3 days with the issue https://github.com/kubernetes/helm/issues/2464#issuecomment-356986809 and after solving that i got into this issue which was solved with your suggestion.
Also see https://github.com/kubernetes/helm/issues/2464#issuecomment-381101015
@chrisglass totally agree with you. It should be part of Helm doc, for instance a FAQ section.

I agree. If someone wants to make a PR and cc myself I'd happily review it.

kubectl -n kube-system edit deploy/tiller-deploy

# add these two lines in container (tiller) scope
serviceAccount: admin-user
serviceAccountName: admin-user

This solution is more secure than creating clusterrolebinding with next params (--clusterrole=cluster-admin --serviceaccount=kube-system:default).

Hi

@shults
I've tried this but i'm still getting this error :
Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system"
Is there something i've missed ?

@falcocoris

1. run helm init
2. kubectl -n kube-system edit deploy/tiller-deploy and upper two lines
3. start observe tiller pods kubectl get pods -w | grep tiller; they should not fail.

No luck yet.! with the above ones

using these lines fixed my pb :

# kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default
clusterrolebinding "add-on-cluster-admin" created
# helm reset     

Error: error unstalling Tiller: timed out waiting for the condition

Note the error at the end, i'm not sure this command did anything in the end but it worked with all of these.