RBAC
RBAC Resources
In Kubernetes, RBAC is used for authorization. RBAC authorization rules are configured using four types of resources.
- Roles: define a set of rules for accessing Kubernetes resources in a namespace.
- RoleBindings: define the relationship between users and roles.
- ClusterRoles: define a set of rules for accessing Kubernetes resources in a cluster (including all namespaces).
- ClusterRoleBindings: define the relationship between users and cluster roles.
Roles and ClusterRoles specify actions that can be performed on specific resources. RoleBindings and ClusterRoleBindings bind Roles to specific users, user groups, or service accounts.

Creating a Role
The definition of a Role is simple. You just specify a namespace and some rules. For example, the following rules allow you to perform GET and LIST operations on pods in the default namespace.
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default # Namespace name: role-example rules: - apiGroups: [""] resources: ["pods"] # The pod can be accessed. verbs: ["get", "list"] # The GET and LIST operations can be performed.
Creating a RoleBinding
After creating a Role, you can bind the Role to a specific user, which is called RoleBinding. The following shows an example:
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rolebinding-example namespace: default subjects: # Specified user - kind: User # Common user name: user-example apiGroup: rbac.authorization.k8s.io - kind: ServiceAccount # Service account name: sa-example namespace: default roleRef: # Specified Role kind: Role name: role-example apiGroup: rbac.authorization.k8s.io
subjects is used to bind the Role to a user. The user can be an external common user or a service account. For details about the two user types, see Service Accounts. The following figure shows the relationships.

Then check whether the authorization takes effect.
In Using a Service Account in a Pod, a pod is created, and the sa-example service account is used. The role-example Role is bound to sa-example. Access the pod and run curl to access resources through the API server to check whether the permissions have been applied.
Use ca.crt and TOKEN corresponding to sa-example for authentication and obtain all pod resources (LIST in Creating a Role) in the default namespace.
$ kubectl exec -it sa-pod -- /bin/sh # export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt # TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) # curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/namespaces/default/pods { "kind": "PodList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/namespaces/default/pods", "resourceVersion": "10377013" }, "items": [ { "metadata": { "name": "sa-example", "namespace": "default", "selfLink": "/api/v1/namespaces/default/pods/sa-example", "uid": "c969fb72-ad72-4111-a9f1-0a8b148e4a3f", "resourceVersion": "10362903", "creationTimestamp": "2020-07-15T06:19:26Z" }, "spec": { ...
If the command output indicates a normal status, sa-example has the required permissions to list pods. Obtain the Deployment again. If information similar to the following is displayed, you do not have the permissions to access the Deployment:
# curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/namespaces/default/deployments ... "status": "Failure", "message": "deployments is forbidden: User \"system:serviceaccount:default:sa-example\" cannot list resource \"deployments\" in API group \"\" in the namespace \"default\"", ...
Roles and RoleBindings apply to namespaces and can isolate permissions to some extent. As shown in the following figure, role-example defined above cannot access resources in the kube-system namespace.

Continue to access the pod. If information similar to the following is displayed, you do not have the permissions:
# curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/namespaces/kube-system/pods ... "status": "Failure", "message": "pods is forbidden: User \"system:serviceaccount:default:sa-example\" cannot list resource \"pods\" in API group \"\" in the namespace \"kube-system\"", "reason": "Forbidden", ...
In a RoleBinding, you can also bind the service accounts of other namespaces by adding them under the subjects field.
subjects: # Specified user - kind: ServiceAccount # Service account name: kube-sa-example namespace: kube-system
Then the kube-sa-example service account in kube-system can perform GET and LIST operations on pods in the default namespace.

ClusterRoles and ClusterRoleBindings
Compared with Roles and RoleBindings, ClusterRoles and ClusterRoleBindings have the following differences:
- There is no need to define the namespace field for a ClusterRole or a ClusterRoleBinding.
- You can use a ClusterRole to define permissions on cluster-level resources.
ClusterRoles and ClusterRoleBindings are used to control cluster-level permissions.
There are many ClusterRoles and ClusterRoleBindings defined by default in Kubernetes.
$ kubectl get clusterroles NAME AGE admin 30d cceaddon-prometheus-kube-state-metrics 6d3h cluster-admin 30d coredns 30d custom-metrics-resource-reader 6d3h custom-metrics-server-resources 6d3h edit 30d prometheus 6d3h system:aggregate-customedhorizontalpodautoscalers-admin 6d2h system:aggregate-customedhorizontalpodautoscalers-edit 6d2h system:aggregate-customedhorizontalpodautoscalers-view 6d2h .... view 30d $ kubectl get clusterrolebindings NAME AGE authenticated-access-network 30d authenticated-packageversion 30d auto-approve-csrs-for-group 30d auto-approve-renewals-for-nodes 30d auto-approve-renewals-for-nodes-server 30d cceaddon-prometheus-kube-state-metrics 6d3h cluster-admin 30d cluster-creator 30d coredns 30d csrs-for-bootstrapping 30d system:basic-user 30d system:ccehpa-rolebinding 6d2h system:cluster-autoscaler 6d1h ...
The most important and commonly used ClusterRoles are as follows:
- view: grants read-only access to the resources in a namespace.
- edit: grants read/write access to most resources in a namespace.
- admin: grants all permissions for the resources in namespaces.
- cluster-admin: grants all permissions for the resources in the cluster.
Run the kubectl describe clusterrole command to view the permissions of each rule.
Typically, the four ClusterRoles are bound to users to isolate permissions. The key idea is that Roles, which define rules and permissions, are independent of users. By using RoleBindings, you can associate Roles with users, allowing flexible control over access permissions.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot