<p>I do understand RBAC and I'm able to create a role using rules en subjects, bind them with a user.</p>

<p>For example this role can only list the pods</p>

<pre><code>kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: development
  name: list-pods
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list"]
</code></pre>

<p>Now we are using namespaces for every environment we have (dev, staging, prd). Now how do I have to provide this role to users in different namespaces? Do I have to create a clusterRole and bind it with a normal rolebinding or do I have to write the above .yaml once for dev, once for uat and once for prd? Are there somewhere rules written about how to handles those cases? </p>

DenCowboy
<blockquote>
  <p>Now how do I have to provide this role to users in different namespaces?</p>
</blockquote>

<p>You do if you want to be able to constrain the ability to list <code>Pod</code>s for that <code>Subject</code> on a per <code>Namespace</code> basis. For example, you might not want people to be able to see <code>Pod</code>s in <code>kube-system</code> (or a hypothetical <code>internal-security</code> namespace). Using the ability to list <code>Pod</code>s as an example makes this hard to imagine, but the ability to list, or view, or both, <code>Secret</code>s or <code>ConfigMap</code>s may make this more tangible. Presumably a <code>Subject</code> can view <code>Secret</code>s for their <em>own</em> project -- or even maybe not -- but not for other projects within the company. That kind of thing.</p>

<p>That gets even more real when one thinks about the ability to <code>exec</code> into arbitrary <code>Pod</code>s -- because that's the biggest risk that I can think of to the safety and confidentiality of applications in the cluster.</p>

<blockquote>
  <p>Do I have to create a clusterRole and bind it with a normal rolebinding</p>
</blockquote>

<p>No, one uses a <code>ClusterRoleBinding</code> for that purpose. "Have to" is not the right question; it depends on whether you want the binding to apply to all namespaces, current <strong>and future</strong>.</p>

<blockquote>
  <p>or do I have to write the above .yaml once for dev, once for uat and once for prd?</p>
</blockquote>

<p>That also depends on whether those <code>Namespaces</code> have identical risk and identical <code>Subject</code>s who access them.</p>

<blockquote>
  <p>Are there somewhere rules written about how to handles those cases?</p>
</blockquote>

<p>Definitely not; there's not one-size-fits-all for cluster security. It all depends on the kind of risk one is trying to drive down.</p>

<p>As a for-your-consideration, you're not obligated to use the RBAC constraints: you can certainly create a <code>ClusterRoleBinding</code> for every <code>Subject</code> to the <code>cluster-admin</code> <code>ClusterRole</code> and voilà, no more permission management. No more safeguards, either, but that's the spectrum.</p>
