<p>There's something I don't quite understand in the way RBAC works in Kubernetes.</p>
<p>I'll state what I understood and what not. Based on the <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="nofollow noreferrer">documentation</a>, the RBAC API defines 4 kinds of kubernetes objects:</p>
<ul>
<li>Role</li>
<li>ClusterRole</li>
<li>RoleBinding</li>
<li>ClusterRoleBinding</li>
</ul>
<p><strong>Role</strong> <br>
A Role defines a set of permissions <strong>within</strong> a specific namespace. The Role definition contains a namepsace field, and the Role object is created within that namespace.  From the docs:</p>
<blockquote>
<p>A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in.</p>
</blockquote>
<p>I suppose that this means that all the rules defined in the Role applies <strong>only</strong> to the objects that are in that namespace. I'll continue supposing this assumption is true, please correct me otherwise.</p>
<p><strong>ClusterRole</strong> <br></p>
<blockquote>
<p>ClusterRole, by contrast, is a non-namespaced resource.</p>
</blockquote>
<p>From what I understand (again, correct me if I'm wrong) a ClusterRole is used to define rules that define permissions regarding to resources that are not bound to any namespace, such as nodes.</p>
<p><strong>RoleBinding</strong>
A RoleBinding object is a namespaced object. Its function is to bind <em>Roles</em> to <em>subjects</em>, i.e. grant subjects (users, ServiceAccounts, groups) with specific Role. It can also bind subjects with ClusterRoles.</p>
<p><strong>ClusterRoleBinding</strong> <br>
Not so much of my interest for the manner of this post.</p>
<h3>The Question</h3>
<p>My questions is, why is there a <code>namespace</code> metadata bit in the RoleBinding definition? If indeed as I assumed in the Role section, a Role grants permissions to objects only in the specified namespace of that Role, then that restriction is already defined in the Role object itself, why is it again defined in the RoleBinding object?</p>
<p>As I'm writing these lines I suddenly think of an optional answer to that question, please tell me if this is correct:</p>
<p>A RoleBinding can also bind a ClusterRole to a list of subjects, and the permissions defined in that ClusterRole will apply only to resources in the namespace specified in the RoleBinding object. That is why we need a <code>namespace</code> bit in the RoleBinding definition. Indeed it is not necessary when we use a RoleBinding to bind a Role rather than a ClusterRole.</p>
<p>Is that correct?</p>

YoavKlein
<p>It is as you said. A <code>RoleBinding</code> needs the <code>namespace</code> specified, because it can also reference a <code>ClusterRole</code> which is not namespaced. So a <code>ClusterRole</code> can be seen (in some cases) as a template for a Role in a specific namespace.</p>
<p>The ClusterRole <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles" rel="nofollow noreferrer"><code>edit</code></a> is a good example for this usecase: you would reference this ClusterRole (not namespaced) in your RoleBinding (namespaced):</p>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1namespace.
kind: RoleBinding
metadata:
  name: editor
  namespace: my-namespace
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io 
</code></pre>
<p>So the user <code>jane</code> would get the permissions defined in the ClusterRole <code>edit</code> but only in the namespace <code>my-namespace</code>.</p>
