<p>Why we need to write the apiGroup key in this definition again and again , if it is the same every time:</p>

<pre><code>kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: web-rw-deployment
 namespace: some-web-app-ns
subjects:
- kind: User
 name: "joesmith@example.com"
 apiGroup: rbac.authorization.k8s.io
- kind: Group
 name: "webdevs"
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: web-rw-deployment
 apiGroup: rbac.authorization.k8s.io
</code></pre>

<ul>
<li>this looks so redudant , that is repeating for everything </li>
<li>if we need to write it , what are the other values </li>
<li>if there are not other values for the field RBAC apiGroup , then k8s should assume that value automatically  <code>apiGroup: rbac.authorization.k8s.io</code></li>
</ul>

<p>this makes the yaml too redundant , is there any way to work around this. can we just skip this key? OR can we declare this somewhere globally.</p>

<p>Good question. The rationale that I can think of is that there may be different APIs in the future that could be supported, for example, <code>rbacv2.authorization.k8s.io</code> and you wouldn't like to restrict references and subjects to just one for compatibility reasons.</p>

<p>My take on this is that it would be nice to have yet another optional global field for <code>RoleBinding</code> besides 'subjects' called something like 'bindingApigroup'. Feel free to open an <a href="https://github.com/kubernetes/kubernetes/issues" rel="nofollow noreferrer">issue</a>: kind/feature, sig/auth and/or sig/api-machinery.</p>

<p>Also, there might be more rationale/details in the <a href="https://github.com/kubernetes/community/tree/master/contributors/design-proposals/auth" rel="nofollow noreferrer">sig-auth</a>  design proposals.</p>
