0
votes

There's something I don't quite understand in the way RBAC works in Kubernetes.

I'll state what I understood and what not. Based on the documentation, the RBAC API defines 4 kinds of kubernetes objects:

  • Role
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding

Role
A Role defines a set of permissions within a specific namespace. The Role definition contains a namepsace field, and the Role object is created within that namespace. From the docs:

A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in.

I suppose that this means that all the rules defined in the Role applies only to the objects that are in that namespace. I'll continue supposing this assumption is true, please correct me otherwise.

ClusterRole

ClusterRole, by contrast, is a non-namespaced resource.

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.

RoleBinding A RoleBinding object is a namespaced object. Its function is to bind Roles to subjects, i.e. grant subjects (users, ServiceAccounts, groups) with specific Role. It can also bind subjects with ClusterRoles.

ClusterRoleBinding
Not so much of my interest for the manner of this post.

The Question

My questions is, why is there a namespace 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?

As I'm writing these lines I suddenly think of an optional answer to that question, please tell me if this is correct:

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 namespace bit in the RoleBinding definition. Indeed it is not necessary when we use a RoleBinding to bind a Role rather than a ClusterRole.

Is that correct?

1

1 Answers

1
votes

It is as you said. A RoleBinding needs the namespace specified, because it can also reference a ClusterRole which is not namespaced. So a ClusterRole can be seen (in some cases) as a template for a Role in a specific namespace.

The ClusterRole edit is a good example for this usecase: you would reference this ClusterRole (not namespaced) in your RoleBinding (namespaced):

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 

So the user jane would get the permissions defined in the ClusterRole edit but only in the namespace my-namespace.