How To Use Kubernetes RBAC (Role-Based Access Control)?

In a nutshell, Role-Based Access Control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an organization. In the context of Kubernetes, RBAC is a security feature that controls access to resources within your cluster. It allows you to specify what actions a user or a group of users can and cannot perform. This is vital in a team environment, where not everyone should have full, unrestricted access to all resources.

Before we go further, let’s briefly understand the architecture of Kubernetes. Kubernetes follows a master-worker node architecture. The master node is responsible for maintaining the desired state (like which applications or other workloads should be running and which nodes they live on), and the worker nodes actually run the workloads.

Kubernetes Architecture

Kubernetes Role-Based Access Control (RBAC) can manage the access and permissions to users and groups based on their requirements as shown below figure the roles or cluster role will be attached to the specified user depending upon their requirements it may be the role that defines permissions within the namespace or cluster role which defines across the namespace.

Kubernetes’ main parts are Control Plane (formerly known as the Master) and the Compute Nodes (or just Nodes).

Control Plane (Master Node): The Control Plane is responsible for maintaining the desired state of the Kubernetes cluster, such as which applications are running and which container images they use. Key components of the control plane were

• API Server (kube-Episerver): This is the front end for the Kubernetes control plane. It is a RESTful interface that etcon handles and exposes APIs and is the main interface for administrators and users to manage the different parts of the cluster.
• etcd: It is a consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data, such as the configuration data and the state of the system.
• Scheduler (kube-scheduler): This is responsible for distributing work or containers across multiple nodes. It looks for newly created Pods with no assigned node and selects a node for them to run on based on factors such as individual and collective resource requirements, hardware/software/policy constraints, etc.
• Controller Manager (kube-controller-manager): This runs the core control loops that regulate the state of the cluster and perform routine tasks. There are different kinds of controllers, such as the Node Controller, Replication Controller, Endpoints Controller, and Service Account & Token Controllers.
• Cloud Controller Manager (cloud-controller-manager): This runs controllers that interact with the underlying cloud providers. It allows the cloud vendor’s technology and the Kubernetes core to evolve independently of each other.
• Compute Nodes (Worker Nodes): All are the machines where the applications are deployed. Each node can host multiple pods. The components on a node include:
  • Kubelet: This is the primary node agent that watches for Pods that have been assigned to its node and ensures that these Pods are running and healthy.
  • Container Runtime: This is the software responsible for running containers. Kubernetes supports several runtimes: Docker, containers, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface).
  • kube-proxy: This is a network proxy that runs on each node to maintain network rules and connection forwarding.
  • Pods: It is the smallest deployable units that can be created and managed in Kubernetes. A Pod can contain one or more containers.

Understanding Key Concepts

RBAC in Kubernetes primarily involves four types of Kubernetes objects: Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings. We also need to understand the concepts of Subjects, Verbs, and Resources as they form the basis of defining access control rules.

Subjects, Verbs, and Resources

Subjects refer to the entity that performs an action. This can be a user, group, or service account. Verbs represent a subject’s actions, such as ‘get’, ‘create’, and ‘delete’. Resources represent the objects on which the actions can be performed, such as ‘pods’, ‘services’, ‘and nodes.For example, if we want to grant a user ‘john’ the permission to ‘delete’ ‘pods’, ‘john’ is the Subject, ‘delete’ is the Verb, and ‘pods’ is the Resource.

Roles

In Kubernetes, a Role is a declaration of the operations that can be performed on a type of Kubernetes resource within a particular namespace. A simple example of a Role could be: You might need to do some pre-checks as below:

Roles. yaml: This Role, named ‘pod-reader’, provides read-only access to Pods in the default namespace.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBindings

It actually grants the permissions defined in a Role to a user or set of users. It holds a list of subjects and a reference to the Role being granted. Here’s an example of a RoleBinding:

RoleBindings.yaml: In this RoleBinding, the ‘pod-reader’ Role is assigned to the user ‘john’. This means that ‘john’ can now read Pods in the default namespace.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoles

ClusterRole is similar to Role. However, while a Role is namespace-specific, a ClusterRole is not. This means that you can define permissions that apply across all namespaces in your cluster. Here’s an example of a ClusterRole.

ClusterRoles.yaml: In this ClusterRole, reading Nodes across the cluster is allowed.

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

ClusterRoleBindings

Similar to a RoleBinding, a ClusterRoleBinding grants the permissions defined in a ClusterRole to a set of users, but it applies cluster-wide.

ClusterRoleBindings.yaml: In this ClusterRoleBinding, the ‘node-reader’ ClusterRole is assigned to the user ‘john’, allowing ‘john’ to read Node information across the entire cluster.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-nodes
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

How to Implement RBAC

In Kubernetes, we typically apply Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings by writing them in YAML files and applying them using kubectl. Firstly, we define Roles and cluster roles. These define the “what” – what can be done? Then, we define your RoleBindings and ClusterRoleBindings. These define the “who” – who can do it? Through the interplay of these RBAC components, you can fine-tune the permissions in your Kubernetes cluster, ensuring that every user can only do what they need to do, and nothing more.

RBAC Usage Scenarios

RBAC can be used in various scenarios to isolate team access, limit resource access, restrict operations, control admin access, and manage service account permissions.

1. Isolating Team Access: Suppose we have multiple teams working in the same Kubernetes cluster but on different applications. You can use RBAC to ensure that the developers from one group don’t accidentally (or intentionally) modify the resources of another team. You do this by creating roles that have access to only specific namespaces and binding those roles to the respective teams.
2. Limiting Resource Access: We might have certain sensitive resources in your cluster, like secrets or config maps, that should only be accessed by certain individuals or applications. With RBAC, you can restrict access to these resources to only those who absolutely need it.
3. Restricting Operations: Not every user or application needs to perform every type of operation. For example, you might have a CI/CD pipeline that only needs to be able to create and delete pods, or a monitoring tool that only needs to be able to read the status of all resources. With RBAC, you can create roles that have only the necessary permissions and no more.
4. Admin Access Control: We might want to give certain users the ability to administer the cluster, but not all users should have this ability. With RBAC, you can create a ClusterRole that has administrative permissions and bind that role to only the appropriate users.
5. Service Account Permissions: Service accounts are a particular type of user that represent applications rather than humans. RBAC can be used to control what these service accounts can do, which is important for maintaining the security of your cluster.