3

We have multiple development teams who work and deploy their applications on kuberenetes. We use helm to deploy our application on kubernetes.

Currently the challenge we are facing with one of our shared clusters. We would like to deploy tiller separate for each team. So they have access to their resources. default Cluster-admin role will not help us and we don't want that.

Let's say we have multiple namespaces for one team. I would want to deploy tiller which has permission to work with resources exist or need to be created in these namespaces.

Team > multiple namespaces tiller using the service account that has the role ( having full access to namespaces - not all ) associated with it.

Tarun Prakash
  • 93
  • 1
  • 5

1 Answers1

2

I would want to deploy tiller which has permission to work with resources exist or need to be created in these namespaces

According to the fine manual, you'll need a ClusterRole per team, defining the kinds of operations on the kinds of resources, but then use a RoleBinding to scope those rules to a specific namespace. The two ends of the binding target will be the team's tiller's ServiceAccount and the team's ClusterRole, and then one RoleBinding instance per Namespace (even though they will be textually identical except for the namespace: portion)

I actually would expect you could make an internal helm chart that would automate the specifics of that relationship, and then helm install --name team-alpha --set team-namespaces=ns-alpha,ns-beta my-awesome-chart and then grant your tiller cluster-admin or whatever more restrictive ClusterRole you wish.

mdaniel
  • 31,240
  • 5
  • 55
  • 58
  • To me it seems we need to create _ClusterRole_ that we would be using with _Tiller_ Next we need to create _RoleBinding_ for to bind _ClusterRole_ and another _RoleBinding_ to bind the same ClusterRole for namespaces that we want this Clousterole to get restricted to. – Tarun Prakash Jun 21 '18 at 06:31
  • Almost; there's no such thing as "RoleBinding for to bind ClusterRole," but the "R.B. to bind [...] C.R. for namespaces" is correct. The R.B. lives in a NS, and associates the team's `tiller` S.A. to the C.R. for _that specific_ NS – mdaniel Jun 22 '18 at 04:34
  • I'm very glad to hear it! If it's convenient for you, please mark the answer as accepted, since it'll help others find the solution – mdaniel Jun 26 '18 at 05:28