<p>I know that you can assign multiple roles to one service account when you want your service account to access multiple namespaces, but what I wonder is how it will behave when you assign to it more than one clusterrole which is cluster scoped. From my perspective, I think that it will choose one of them but I'm not sure.</p>

<blockquote>
<p>Permissions are purely additive (there are no &quot;deny&quot; rules).</p>
</blockquote>
<p><a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="noreferrer">reference</a></p>
<p>This is the golden 🥇 rule here that we must memorize for kubernetes RBAC roles.</p>
<p>&quot;purely additive&quot; means always <strong>ALLOW</strong> no revoke.</p>
<p>Hence, &quot;purely additive&quot; means there are neither <strong>conflicts</strong> nor <strong>order of precedence</strong>.</p>
<ul>
<li>It's not like <strong>AWS IAM policies</strong> where we have DENY and ALLOW .. That's time, we have to know which one has the highest order of precedence.</li>
<li>It's not like also <strong>subnets ACL</strong> , where we have DENY and ALLOW .. That's time, we need to assign number for each rule. This number will decide the order of precedence.</li>
</ul>
<p>Example:</p>
<pre class="lang-yaml prettyprint-override"><code>---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # &quot;namespace&quot; omitted since ClusterRoles are not namespaced
  name: pod-reader
rules:
- apiGroups: [&quot;&quot;]
  resources: [&quot;pods&quot;]
  verbs: [&quot;get&quot;, &quot;watch&quot;, &quot;list&quot;]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # &quot;namespace&quot; omitted since ClusterRoles are not namespaced
  name: node-reader
rules:
- apiGroups: [&quot;&quot;]
  resources: [&quot;nodes&quot;]
  verbs: [&quot;get&quot;, &quot;watch&quot;, &quot;list&quot;]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: pod-reader
subjects:
- kind: User
  name: abdennour
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: node-reader
subjects:
- kind: User
  name: abdennour
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

</code></pre>
<p>as you can see in this example, the user Abdennour should have at the end the wide read access for both: nodes &amp; pods.</p>
