A RoleBinding grants a user, group, or ServiceAccount the permissions defined by a Role or ClusterRole within a namespace. The Role or ClusterRole defines allowed resources and verbs; the RoleBinding connects those rules to subjects. This is how RBAC authorizes a request without giving the subject broader access than the task requires. section 3.1.1 section 3.3
Choose the binding and permission source by scope:
- Use a RoleBinding with a Role for permissions defined in a namespace. section 3.1.1
- Use a RoleBinding with a ClusterRole to grant that ClusterRole’s permissions within the binding’s namespace. An existing ClusterRole such as view may save setup time. section 3.1.1 section 3.1.2
- Use a ClusterRoleBinding for cluster-wide grants. A ClusterRoleBinding cannot refer to a Role. section 3.1.1
Grant pod-reading access to a user
Create the permission rules, then bind them in the default namespace: kubectl create role pod-reader --verb=get,list,watch --resource=pods kubectl create rolebinding pod-reader-binding --role=pod-reader --user=carol kubectl get rolebinding pod-reader-binding -o yaml kubectl auth can-i get pods -n default --as carol kubectl auth can-i delete pods -n default --as carol The checks return yes for get and no for delete. The binding points to the Role; it does not add delete to the Role’s rules. For a group instead, use --group=developers. To bind a ServiceAccount, use a namespace-qualified subject such as --serviceaccount=default:nomount-sa, then test with --as system:serviceaccount:default:nomount-sa. section 3.1.1 section 3.2 section 3.3
$ kubectl create rolebinding pod-reader-binding --role=pod-reader --user=carol rolebinding.rbac.authorization.k8s.io/pod-reader-binding created $ kubectl get rolebinding pod-reader-binding -oyaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: creationTimestamp: "2022-03-29T04:22:35Z" name: pod-reader-binding namespace: default resourceVersion: "566785" uid: 9f7d1036-9123-4288-94cf-ef527aa090d0 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pod-reader subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: carol
The generated YAML makes the two essential parts visible: roleRef names the Role, while subjects names the User; metadata places the RoleBinding in the default namespace. section 3.1.1
A binding does not create a user or authenticate one. A user can authenticate with a client certificate and kubeconfig, then receive only the access their bindings allow. If a request is forbidden, inspect the binding’s namespace, roleRef, and subjects, and use kubectl auth can-i with --as to check the requested verb and resource. Practice both an allowed read and a denied delete before treating the grant as complete. section 3.2 section 3.1.1
