What is RBAC in Kubernetes?

March 05, 2026

4 min read

Page content

In this post I will show you how you can use RBAC in kubernetes.

What is RBAC?

RBAC stands for Role-Based Access Control. It is an approach that is used for restricting access to resources for users based on roles. Kubernetes uses RBAC for authorization, for example to give access to users and groups to certain Kubernetes resources. It uses roles to add or remove permissions. For Kubernetes, RBAC is the way to restrict who can access what within the cluster.

Why RBAC?

A Kubernetes cluster is being used by multiple users. These users can be different types of users, for example developers, testers, application administrators, and cluster administrators. These groups of users need different permissions to do their jobs. That is where the notion of RBAC or Role-Based Access Control comes into play. You can create different roles for these groups and associate the roles with the users or groups.

RBAC

Role

A role defines what you can do to a specific Kubernetes resource. The role contains two main parts: one representing what permissions you have and another representing the Kubernetes resource in the Kubernetes API structure.

Here is a simple example for Roles, where the user has permission to just get and list the pods:

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

ClusterRole

Roles are used to assigning resources for a namespace, but if you need to assign resources on a cluster level, you need to use ClusterRole. It is similar to Roles, but it can grant permissions that are cluster-scoped such as giving resource permissions across all namespaces in the cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
    creationTimestamp: null
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
rules:
  - apiGroups:
    - "*"
  resources:
    - "*"
      verbs:
        - "*"

RoleBinding

RoleBinding is used for granting permission to a Subject in a Kubernetes cluster. Subjects can be users, service accounts or groups trying to access Kubernetes API.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: elasticsearch
  namespace: default
roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: elasticsearch
subjects:
- kind: User
  name: John
  namespace: default

Below is an example of RoleBinding where roleRef is being used to bind user John with the previously created elasticsearch role in the default namespace.

ClusterRoleBinding

ClusterRoleBinding is used to grant permission to a subject on a cluster-level in all the namespaces.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
   name: cluster-admin
roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
subjects:
 - apiGroup: rbac.authorization.k8s.io
   kind: Group
   name: masters

What can I bind with what?

Usually you use RoleBinding to bind Role and ClusterRoleBinding to bind ClusterRole, but you can use RoleBinding to bind ClusterRole to a specific namespace. It is a best practice to create global ClusterRoles for specific tasks and bind them to namespaces with RoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding-to-default
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: template-namespaced-resources---developer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: developer-team
  namespace: default

Aggregated ClusterRoles

You can aggregate several ClusterRoles into one combined ClusterRole. If you create a ClusterRole with aggregationRule the controller in the Kubernetes cluster will search fo the ClusterRoles with the matching labels and combines ther roles into the Aggregated ClusterRole.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # The control plane automatically fills in the rules
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# When you create the "monitoring-endpoints" ClusterRole,
# the rules below will be added to the "monitoring" ClusterRole.
rules:
- apiGroups: [""]
  resources: ["services", "endpointslices", "pods"]
  verbs: ["get", "list", "watch"]

The default ClusterRoles are using ClusterRole aggregation. This lets you include rules for custom resources defined by CustomResourceDefinition to extend the default roles.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Add these permissions to the "admin" and "edit" default roles.
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # Add these permissions to the "view" default role.
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]