Updated on 2025-08-22 GMT+08:00

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.

Figure 1 Role binding

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.

Figure 2 Binding a Role to a user

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.

Figure 3 Role and RoleBinding applied to namespaces

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.

Figure 4 Cross-namespace access

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.