Configuring Your Cluster For helm

Configuring Your Cluster For helm

In my previous articles, I explained how to configure RBAC for Service Accounts in Kuberentes.

However, as of this writing (Sep 2017), there’s one more thing that I needed to handle, related to configuring RBAC, and that was helm.

RBAC and Helm

By default helm installs a deployment called tiller-deploy into the kube-system namespace. When you enable RBAC, though, doing things like helm list while running things in your regular namespace requires extra authorization to access the resources in the kube-system namespace.

This has been addressed in recent versions of helm by adding the --service-account flag to helm init , so now you can specify the name of a service account that has proper permissions to access tiller-deploy when install helm.

This works perfectly if you are constructing a cluster by hand, or only once, but I needed to be able to create a mechanism in which repeatedly calling the setup tool does The Right Thing, and possibly fix previous problems, if any.

Automation Friendly Setup

The information to make this automation-friendly can be found in the original GitHub issue:

Specifically, this comment nails it:

And here’s the copy of it, in case you really don’t want to click those links:

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

The point here is to create a Service Account, create a ClusterRoleBinding to cluster-admin so helm is allowed to do interesting things, and then patching the tiller-deploy instance. By doing this through patching, we can safely and gracefully automate the task of apply authorization for both when we have already installed helm, or we’re installing it anew.

And so now, you’re ready to use helm in an RBAC enabled world.