<p>I know role is used to grant permission to users or service account to perform operation in specific namespace. <br>
A typical role definition may be like this</p>

<pre><code>kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: mynamespace
  name: my-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
</code></pre>

<p>but in definition of service account, we can also see the namespace field</p>

<pre><code>apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-serviceac
  namespace: mynamespace
</code></pre>

<p>My questions are: <br>
1. Is namespace scope applied to user/service account or role?<br>
2. what if the namespace in service account and role are different<br></p>

<p>role binding definition for reference</p>

<pre><code>kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: my-rolingbinding
  namespace: mynamespace
subjects:
- kind: ServiceAccount
  name: my-serviceac
  namespace: mynamespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: my-role
</code></pre>

HKIT
<ol>
<li>Namespace is applied to all three of role, service account and role binding.</li>
<li>It does not matter if the namespace is different in role and service account. You can still create a role binding but the service account will get access to perform verbs on the resources only in the namespace as defined in the role and the role-binding need to be created in the same namespace as the role.</li>
</ol>

<hr>

<pre><code>kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: mynamespace
  name: my-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-serviceac
  namespace: default
</code></pre>

<hr>

<pre><code>kubectl create rolebinding my-role-binding --role=my-role --serviceaccount=default:myserviceac -n mynamespace
</code></pre>

<p>And then checked the permission of the service account</p>

<pre><code>kubectl auth can-i get pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes
kubectl auth can-i watch pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes

kubectl auth can-i list pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes
</code></pre>

<hr>

<pre><code>kubectl auth can-i get pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n default --as=system:serviceaccount:default:myserviceac
no
</code></pre>

<p>As we can see the service account has got permission to get,watch,list pods in mynamespace but does not have same permission in default namespace although the service account is located in default namespace.</p>

<p>Now if I delete the rolebinding and create it in default namespace instead of mynamespace.</p>

<pre><code>kubectl create rolebinding my-role-binding --role=my-role --serviceaccount=default:myserviceac -n default
</code></pre>

<hr>

<pre><code>kubectl auth can-i get pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n default --as=system:serviceaccount:default:myserviceac
no
</code></pre>

<hr>

<pre><code>kubectl auth can-i get pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no
</code></pre>

<hr>

<p>As it can be seen that the permission is not applied anymore.</p>
