Body: <p>I noticed that in our cluster, we have dozens of roles which are identical if you ignore unique fields like <code>creationTimestamp</code>, <code>uid</code>, <code>resourcesVersion</code>, <code>labels</code>, <code>name</code> and <code>namespace</code>:</p>
  <p>The following will dump all the roles in the cluster into one file per role after deleting the unique fields:</p>
  <pre><code>kubectl get roles -A -o json | jq -c '.items[] | map(del(.. | .creationTimestamp?, .uid?, .resourceVersion?, .labels?, .name?, .namespace?))' | split -l 1
  </code></pre>
  <p>And then counting files with identical content:</p>
  <pre><code>❯ md5sum *|  awk '{print $1}' | sort | uniq -c | awk '$1 &gt; 1'
    73 9ced71c5d581cde3c4e94c542ca58f42
    11 d7f556fbe1b2f62ae931b735ebe75349
  </code></pre>
  <p>I was wondering what would be pros vs cons for replacing these identical roles by a single <code>ClusterRole</code> which is then bound where it's needed.</p>
  <p>I suppose that it's cleaner to have fewer redundant resources in the cluster, but would it push me into a corner that will make me regret it in the future?</p>
  
Comments: CC BY-SA 4.0
Comments: 2024-10-18T09:06:19.990Z
Comments: Eliminates redundancy but I guess it could come back to bite you if you need to apply specific labels, annotations, or slightly different permissions for roles in certain namespaces in the future.
Comments: hakim00
Comments: CC BY-SA 4.0
Comments: 2024-10-20T22:42:52.317Z
Comments: @hakim00 thanks for your thoughts.
  Wouldn't this be mitigated by sharing the cluster role as long as it's viable and just switch "snowflakes" to a separate role if and when the need comes up?
Comments: Capt. Crunch
Tags: <kubernetes><role-based-access-control>
Title: Is there a best practice around sharing a role with multiple namespaces or services?
UserDisplayName: Capt. Crunch
ThreadText: # Is there a best practice around sharing a role with multiple namespaces or services?
  
  (Asked by: username_0 on 2024-10-18)
  
  I noticed that in our cluster, we have dozens of roles which are identical if you ignore unique fields like `creationTimestamp`, `uid`, `resourcesVersion`, `labels`, `name` and `namespace`:
  
  The following will dump all the roles in the cluster into one file per role after deleting the unique fields:
  
  ```
  kubectl get roles -A -o json | jq -c '.items[] | map(del(.. | .creationTimestamp?, .uid?, .resourceVersion?, .labels?, .name?, .namespace?))' | split -l 1
  
  ```
  
  And then counting files with identical content:
  
  ```
  ❯ md5sum *|  awk '{print $1}' | sort | uniq -c | awk '$1 > 1'
    73 9ced71c5d581cde3c4e94c542ca58f42
    11 d7f556fbe1b2f62ae931b735ebe75349
  
  ```
  
  I was wondering what would be pros vs cons for replacing these identical roles by a single `ClusterRole` which is then bound where it's needed.
  
  I suppose that it's cleaner to have fewer redundant resources in the cluster, but would it push me into a corner that will make me regret it in the future?
  
  **Tags:** kubernetes, role-based-access-control
  
  > **Comments:**
  > **username_1**: Eliminates redundancy but I guess it could come back to bite you if you need to apply specific labels, annotations, or slightly different permissions for roles in certain namespaces in the future.  
  > **username_0**: @username_1 thanks for your thoughts. Wouldn't this be mitigated by sharing the cluster role as long as it's viable and just switch "snowflakes" to a separate role if and when the need comes up?  
  
  ---
  
  ## 0 answers
  
  