Helm. Tiller. You have probably heard these words in reference to the former's description as the Kubernetes Package Manager. The later is the server/cluster-side element that helm communicates with to do its work. The common practice is to create a role binding between tiller's service account and the cluster-admin role. This allows for installation/management/updating-of/etc of any Kubernetes object.
Like with most RBAC configuration that denies haphazard assignment of the cluster-admin role, once it works it makes sense. Getting to that state for random-kubernetes-thing-X can be a time-consuming and often frustrating task.
The doc for properly setting up tiller in an RBAC-enabled cluster is... elusive. The following RBAC definition was observed on some issue board (gitlab-runner?)--I was fortunate enough to recognize this gem for what it was and wrote it down before loosing track of that particular issue forever.
Whoever's brain is the origin of this knowledge, I owe you a drop of something nice.
Apply this and remove one more thing that runs with needlessly powerful privileges!
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: tiller-for-mortals rules: - apiGroups: - "" resources: - pods verbs: - list - apiGroups: - "" resources: - pods/portforward verbs: - create
Once this manifest is applied to the namespace occupied by tiller, a rolebinding is all it takes to have access to helm/tiller's functions.
$ kubectl --namespace=tillerhut create rolebinding helm4stephen \ --service-account=tokens:stephen-at-revsys --role=tiller-for-mortals
NOTE
The constraint is not directly with tiller but with the rolebinding. This role can (and is) used to bind to a gitlab-runner deployment used for CI-driven deployments. The runner doesn't have direct unfettered access to the host cluster--it just has gRPC access to an internal service with unfettered access to the cluster.
Baby steps, dig?
Thanks for reading!
Stephen
