<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>

CC BY-SA 4.0
2024-10-18T09:06:19.990Z
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.
hakim00
CC BY-SA 4.0
2024-10-20T22:42:52.317Z
@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?
Capt. Crunch
<kubernetes><role-based-access-control>
Is there a best practice around sharing a role with multiple namespaces or services?
Capt. Crunch
# 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

