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

<p>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.</p>

<p>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.</p>

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

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

<p>According to <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding" rel="nofollow noreferrer">the fine manual</a>, you'll need a <code>ClusterRole</code> per team, defining the kinds of operations on the kinds of resources, but then use a <strong><code>RoleBinding</code></strong> to scope those rules to a specific namespace. The two ends of the binding target will be the team's tiller's <code>ServiceAccount</code> and the team's <code>ClusterRole</code>, and then one <code>RoleBinding</code> instance per <code>Namespace</code> (even though they will be textually identical except for the <code>namespace:</code> portion)</p>

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