Understanding Role-Based Access Control (RBAC) in Kubernetes: Roles, RoleBindings, and ClusterRoles

Securing Kubernetes clusters is a critical responsibility for administrators, especially in multi-user environments where multiple teams interact with cluster resources. Kubernetes Role-Based Access Control (RBAC) provides a fine-grained permission system to ensure that users, groups, and service accounts only have access to the resources they need.

In this article, we will explore how RBAC controls access to Kubernetes resources and walk through practical scenarios to implement Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings for better security and operational control.

How RBAC Works in Kubernetes

RBAC controls permissions by defining who (subjects like users, groups, or service accounts) can access what (resources like pods, secrets, or deployments) and how (actions like read, write, delete, or update).

RBAC is managed using four key components:

Roles and RoleBindings operate within a single namespace, while ClusterRoles and ClusterRoleBindings apply across the entire cluster.

Scenario 1: Granting Read-Only Access to Pods in a Namespace

Context

A developer needs read-only access to all pods in the dev namespace. The developer should be able to list and view pod details but should not be able to modify, delete, or create new pods.

Step 1: Define a Role for Read-Only Pod Access

The following Role grants only read permissions to pods in the dev namespace:

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

Apply the Role:

kubectl apply -f pod-reader-role.yaml        

This Role does not grant write access, ensuring the principle of least privilege is maintained.

Step 2: Bind the Role to a User Using RoleBinding

Now, we need to assign the pod-reader Role to a specific developer (dev-user). This is done using a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: dev
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io        

Apply the RoleBinding:

kubectl apply -f role-binding.yaml        

Now, the dev-user has read-only access to pods in the dev namespace.

Step 3: Verify the Access Permissions

To verify if the permissions are correctly set, switch to dev-user and try listing pods:

kubectl auth can-i list pods --namespace=dev --as=dev-user        

Expected Output:

yes        

Now, try to delete a pod:

kubectl auth can-i delete pods --namespace=dev --as=dev-user        

Expected Output:

no        

This confirms that RBAC is correctly configured to restrict write operations while allowing read-only access.

Scenario 2: Granting Cluster-Wide Admin Access Using ClusterRoles

Context

The Kubernetes operations team needs full administrative access across all namespaces. Instead of creating multiple RoleBindings, we can define a ClusterRole that grants complete control over the cluster.

Step 1: Define a ClusterRole for Admin Access

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-role
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]        

Apply the ClusterRole:

kubectl apply -f cluster-admin-role.yaml        

This role grants full access to all Kubernetes resources across all namespaces.

Step 2: Bind the ClusterRole to an Admin User

Now, let’s create a ClusterRoleBinding to assign the cluster-admin-role to an administrator (admin-user).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: admin-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin-role
  apiGroup: rbac.authorization.k8s.io        

Apply the ClusterRoleBinding:

kubectl apply -f cluster-role-binding.yaml        

The admin-user now has full control over the entire Kubernetes cluster.

Step 3: Verify the Permissions

kubectl auth can-i create deployments --as=admin-user        

Expected Output:

yes        

This confirms that the admin-user has unrestricted access across the cluster.

Scenario 3: Granting Read-Only Access to Kubernetes Secrets in All Namespaces

Context

A security auditing team requires read-only access to all Kubernetes secrets, but they should not be able to modify or delete them.

Step 1: Define a ClusterRole for Secret Read-Only Access

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

Apply the ClusterRole:

kubectl apply -f secret-reader-role.yaml        

Step 2: Bind the ClusterRole to a Group Using ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: secret-reader-binding
subjects:
- kind: Group
  name: security-auditors
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io        

Apply the ClusterRoleBinding:

kubectl apply -f secret-reader-binding.yaml        

Now, all users in the security-auditors group can list and read Kubernetes secrets but cannot modify them.

Key Takeaways

• RBAC secures Kubernetes by defining fine-grained access controls.
• Roles and RoleBindings are namespace-scoped, while ClusterRoles and ClusterRoleBindings are cluster-wide.
• RBAC follows the principle of least privilege, ensuring only necessary permissions are granted.
• Using RBAC, you can enforce access restrictions for users, groups, and service accounts.

What’s Next?

Are you using RBAC effectively in your Kubernetes clusters? What challenges have you faced when configuring access control? Share your thoughts in the comments below.

Follow Bavithran M for more DevOps, Kubernetes, and cloud-native insights.

If you found this useful, consider sharing it with your network.