{"id":8293,"date":"2023-12-09T00:23:17","date_gmt":"2023-12-09T00:23:17","guid":{"rendered":"https:\/\/cheapwindowsvps.com\/blog\/understanding-role-based-access-control-rbac-in-kubernetes\/"},"modified":"2025-01-20T11:43:14","modified_gmt":"2025-01-20T11:43:14","slug":"understanding-role-based-access-control-rbac-in-kubernetes","status":"publish","type":"post","link":"https:\/\/cheapwindowsvps.com\/blog\/understanding-role-based-access-control-rbac-in-kubernetes\/","title":{"rendered":"Understanding Role-Based Access Control (RBAC) in Kubernetes"},"content":{"rendered":"
In a previous post in this Kubernetes guide<\/a>, you learned about deploying stateful applications with Kubernetes StatefulSets. Today, we will discuss role-based access control (RBAC) in Kubernetes, which controls who can access Kubernetes cluster resources. It uses roles and role bindings to grant permissions to subjects, such as users, groups, or service accounts.<\/div>\n

Verify Kubernetes API supports RBAC<\/h2>\n

The first step is ensuring that RBAC is enabled in the Kubernetes API server. To do so, look at the –authorization-mode flag of the kube-apiserver YAML manifest.<\/p>\n

sudo cat \/etc\/kubernetes\/manifests\/kube-apiserver.yaml | grep authorization-mode<\/pre>\n
Ensuring RBAC is enabled in the Kubernetes API server<\/a><\/div>\n
You are good to go if you see RBAC listed as shown in the screenshot. Here, Node refers to node authorization mode, which authorizes API requests from kubelets, and RBAC denotes that RBAC is enabled. Once RBAC is enabled, it declares four object kinds in the Kubernetes cluster: Roles, RoleBinding, ClusterRoles, and ClusterRoleBinding. You can see these resources by running the kubectl api-resources | grep role<\/em> command, as shown in the screenshot below:<\/p>\n
Viewing API resources in Kubernetes<\/a><\/div>\n
This command returns each object’s API version and kind, as shown in the screenshot above. Notice that roles<\/em> and rolebindings<\/em> are namespaced, meaning they only apply to the resources within the same namespace in which they are created. The clusterroles<\/em> and clusterrolebindings<\/em> objects,<\/em> on the other hand, are not namespaced, which means they work clusterwide regardless of the namespace. You will understand them better in the next section.<\/p>\n
Understanding a role<\/h2>\n
In Kubernetes, a role defines a set of rules that specifies which operations are allowed on what resources. For instance, the role.yaml<\/em> configuration file below creates a pod-reader<\/em> role in the default namespace.<\/p>\n
apiVersion: rbac.authorization.k8s.io\/v1<\/pre>\n
kind: Role<\/p>\n
metadata:<\/p>\n
namespace: default<\/p>\n
name: pod-reader<\/p>\n
rules:<\/p>\n
– apiGroups: [“”]<\/p>\n
resources: [“pods”, “pods\/log”]<\/p>\n
verbs: [“get”, “watch”, “list”]<\/p>\n
Viewing a role manifest in Kubernetes<\/a><\/p>\n
Representation of a role manifest in Kubernetes.<\/p>\n
The elements of a role manifest are:<\/p>\n