"Mastering Kubernetes RBAC: Roles, Bindings, and Identities Explained"

Role-Based Access Control (RBAC) is a way in which we can regulate the access to a resource, based on the roles assigned to users, and groups in the organization.

The RBAC API has 4 kinds of k8s objects:

Role
ClusterRole
RoleBinding
ClusterRoleBinding

Role And ClusterRole

The RBAC Role or ClusterRole contains the rules applicable to the user. These rules are nothing but a set of permissions that the user has.

A Role always sets permissions to the user with the specified namespace, so whenever you create a Role, you have to specify the namespace explicitly. On the other hand, ClusterRole applies to the entire Kubernetes cluster and is not limited to any namespace.

Yaml to create a Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default # Namespace-specific role
  name: custome-role # Name of the Role
rules:
- apiGroups: [""] 
  resources: ["pods"] # This Role grants permissions on Pods
  verbs: ["get", "watch", "list"] # Allowed actions

YAML to create a ClusterRole

Here you don't have to specify the namespace, as the role is applicable on the cluster level.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Identities OR Subjects

In Kubernetes, User, Group, and ServiceAccount fall under the category of identities or subjects in the context of Role-Based Access Control (RBAC). They represent entities that can be granted permissions to access and interact with Kubernetes resources.

User: Users are external identities typically authenticated through external systems. They are not managed directly by Kubernetes but can be assigned roles via RBAC.
Group: Groups are collections of users, managed outside of Kubernetes. Groups help in organizing users and can be assigned roles collectively via RBAC.
ServiceAccount: Service accounts are Kubernetes-native identities used by processes within the cluster (e.g., applications or services). They are managed directly by Kubernetes and are used for granting permissions to these processes.

RoleBinding and ClusterRoleBinding

So, in the Role and ClusterRole, you specify the set of permissions, but as of now you have just specified it, but it is not attached to any user or group. So a RoleBinding helps to attach a Role to a user, group. As Role and ClusterRole, the RoleBinding is specific to a certain namespace whereas ClusterRoleBinding is applicable cluster-wide.

After you create a binding, you cannot change the Role or ClusterRole that it refers to. If you try to change a binding's roleRef, you get a validation error. If you do want to change the roleRef for a binding, you need to remove the binding object and create a replacement.

YAML to create a RoleBinding

This role binding allows "dummy_user" to read pods in the specified namespace. Just the pre-requisite is, you have to have a Role named custom-role in that namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-namespace-pods
  namespace: default
subjects:
- kind: User
  name: dummy_user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: custom-role # Role name of earlier created role
  apiGroup: rbac.authorization.k8s.io

YAML to create a ClusterRoleBinding

No namespace needs to be specified here as the Binding is applicable to a cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader # CluserRole name of earlier created ClusterRole
  apiGroup: rbac.authorization.k8s.io

Verbs applicable to Role & ClusterRole:

get: Allows the subject to retrieve the details of a specific resource.
list: Allows the subject to list multiple resources of the same type.
watch: Allows the subject to continuously monitor changes to resources in real-time.
create: Allows the subject to create a new resource.
update: Allows the subject to modify an existing resource.
patch: Allows the subject to apply partial updates to an existing resource.
delete: Allows the subject to remove a resource.

NOTE: In Kubernetes, both patch and update are verbs used to modify existing resources, but they differ in how they apply changes and the extent of those changes. update replaces the entire resource specification, whereas patch modifies only specific fields of the resource.

Kubernetes RBAC