RoleBindings and ClusterRoleBindings in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Difference between RoleBinding and ClusterRoleBinding

Which statement correctly describes the difference between a RoleBinding and a ClusterRoleBinding in Kubernetes?

A RoleBinding is deprecated; ClusterRoleBinding is the only supported binding type.

B RoleBinding grants permissions cluster-wide; ClusterRoleBinding grants permissions within a specific namespace.

C RoleBinding and ClusterRoleBinding both grant permissions only within a namespace but differ in API versions.

D RoleBinding grants permissions within a specific namespace; ClusterRoleBinding grants permissions cluster-wide.

💡 Hint

Think about the scope of permissions each binding type controls.

A RoleBinding assigns permissions to users or groups within a single namespace. A ClusterRoleBinding assigns permissions across the entire cluster, spanning all namespaces.

💻 Command Output

intermediate

kubectl command output for RoleBinding listing

What is the output of the command kubectl get rolebindings -n dev if there is one RoleBinding named read-pods in the dev namespace?

Kubernetes

kubectl get rolebindings -n dev

A

NAME        ROLE                 AGE
read-pods   Role/read-pods-role   10d

B

NAME        CLUSTERROLE          AGE
read-pods   ClusterRole/read-pods 10d

C No resources found in dev namespace.

D error: the server doesn't have a resource type "rolebindings"

💡 Hint

Consider the resource type and namespace specified in the command.

The command lists RoleBindings in the dev namespace. The output shows the RoleBinding name, the Role it references, and its age.

❓ Configuration

advanced

Correct ClusterRoleBinding YAML for cluster-wide admin access

Which YAML snippet correctly creates a ClusterRoleBinding named cluster-admin-binding that grants the cluster-admin ClusterRole to the user alice?

A

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

B

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

C

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

D

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

💡 Hint

Check the kind of binding, subject kind, and roleRef kind carefully.

The binding must be ClusterRoleBinding to grant cluster-wide permissions. The subject kind must be User for a user named alice. The roleRef must reference a ClusterRole named cluster-admin.

❓ Troubleshoot

advanced

Error when creating RoleBinding with cluster-wide ClusterRole

You try to create a RoleBinding in namespace test that references the cluster-admin ClusterRole, but get an error. What is the most likely cause?

A The namespace <code>test</code> does not exist.

B RoleBindings cannot reference ClusterRoles; only ClusterRoleBindings can.

C The <code>cluster-admin</code> ClusterRole does not exist.

D RoleBinding subjects must be service accounts only.

💡 Hint

Think about the scope of RoleBindings and ClusterRoles.

RoleBindings can reference Roles or ClusterRoles, but when referencing a ClusterRole, the RoleBinding is limited to the namespace. However, some cluster-wide ClusterRoles like cluster-admin are intended to be bound cluster-wide using ClusterRoleBinding. Some Kubernetes versions or policies may restrict RoleBindings from referencing cluster-wide ClusterRoles.

🔀 Workflow

expert

Sequence to grant namespace admin rights to a user

Arrange the steps in the correct order to grant a user named bob admin rights in the production namespace using Kubernetes RBAC.

A 3,1,2,4

B 1,3,2,4

C 3,2,1,4

D 2,1,3,4

💡 Hint

Think about prerequisites before creating resources and verifying access last.

First, ensure the namespace exists. Then create the Role with admin permissions. Next, bind the Role to the user with a RoleBinding. Finally, test the user's access.

Practice

1. What is the main difference between a RoleBinding and a ClusterRoleBinding in Kubernetes?

easy

A. RoleBinding and ClusterRoleBinding are exactly the same.

B. RoleBinding grants permissions cluster-wide, while ClusterRoleBinding grants permissions within a single namespace.

C. RoleBinding is used only for system users, ClusterRoleBinding is for regular users.

D. RoleBinding grants permissions within a single namespace, while ClusterRoleBinding grants permissions cluster-wide.

Solution

1. Step 1: Understand RoleBinding scope

   RoleBinding assigns permissions only inside one namespace.

2. Step 2: Understand ClusterRoleBinding scope

   ClusterRoleBinding assigns permissions across the entire cluster, not limited to a namespace.

3. Final Answer:

   RoleBinding is namespace-scoped; ClusterRoleBinding is cluster-scoped. -> Option D

4. Quick Check:

   Scope difference = RoleBinding grants permissions within a single namespace, while ClusterRoleBinding grants permissions cluster-wide. [OK]

Hint: Remember: RoleBinding = namespace, ClusterRoleBinding = whole cluster [OK]

Common Mistakes:

• Confusing the scope of RoleBinding and ClusterRoleBinding
• Thinking both bindings work cluster-wide
• Assuming RoleBinding is for system users only

2. Which of the following is the correct syntax to create a RoleBinding in Kubernetes YAML?

easy

A. apiVersion: v1
kind: RoleBinding
metadata:
name: read-pods
subjects:
- kind: User
name: jane
roleRef:
kind: Role
name: pod-reader

B. apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io

C. apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-pods
subjects:
- kind: User
name: jane
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io

D. apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
subjects:
- kind: User
name: jane
roleRef:
kind: ClusterRole
name: pod-reader
apiGroup: rbac.authorization.k8s.io

Solution

1. Step 1: Check apiVersion and kind

   Correct apiVersion for RoleBinding is rbac.authorization.k8s.io/v1 and kind is RoleBinding.

2. Step 2: Validate subjects and roleRef fields

   Subjects must include kind, name, and apiGroup. roleRef must reference a Role with correct apiGroup.

3. Final Answer:

   apiVersion: rbac.authorization.k8s.io/v1, kind: RoleBinding, with complete subjects including apiGroup, and roleRef to Role. -> Option B

4. Quick Check:

   Correct apiVersion and fields = apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods subjects: - kind: User name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io [OK]

Hint: RoleBinding YAML needs apiVersion rbac.authorization.k8s.io/v1 and kind RoleBinding [OK]

Common Mistakes:

• Using wrong apiVersion or kind
• Omitting apiGroup in subjects or roleRef
• Confusing RoleBinding with ClusterRoleBinding syntax

3. Given this YAML snippet for a ClusterRoleBinding:

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

What permission scope does user alice get?

medium

A. Permissions cluster-wide with cluster-admin rights

B. No permissions because ClusterRoleBinding requires a ServiceAccount subject

C. Permissions only in the default namespace

D. Permissions only in the namespace where the ClusterRoleBinding is created

Solution

1. Step 1: Identify the binding type and role

   The YAML defines a ClusterRoleBinding that binds user alice to the cluster-admin ClusterRole.

2. Step 2: Understand ClusterRoleBinding scope

   ClusterRoleBinding grants permissions cluster-wide, so alice has admin rights across all namespaces.

3. Final Answer:

   User alice has cluster-wide admin permissions. -> Option A

4. Quick Check:

   ClusterRoleBinding + cluster-admin = cluster-wide admin [OK]

Hint: ClusterRoleBinding with cluster-admin role = full cluster access [OK]

Common Mistakes:

• Assuming permissions are limited to one namespace
• Thinking only ServiceAccounts can be subjects
• Confusing ClusterRoleBinding with RoleBinding scope

4. You applied this YAML to create a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
subjects:
- kind: User
  name: bob
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

But bob cannot list pods in the namespace. What is the likely problem?

medium

A. The subjects field is missing apiGroup for the user.

B. The roleRef kind should be ClusterRole instead of Role.

C. The RoleBinding must be created in the kube-system namespace.

D. The user bob does not exist in Kubernetes.

Solution

1. Step 1: Check subjects field completeness

   The subjects entry for user bob lacks the required apiGroup field, which is needed to identify the user correctly.

2. Step 2: Understand impact of missing apiGroup

   Without apiGroup, Kubernetes cannot match the user to the RoleBinding, so permissions are not granted.

3. Final Answer:

   Missing apiGroup in subjects causes permission failure. -> Option A

4. Quick Check:

   Subjects need apiGroup for user binding [OK]

Hint: Always include apiGroup in subjects for users [OK]

Common Mistakes:

• Omitting apiGroup in subjects
• Confusing Role and ClusterRole in roleRef
• Assuming namespace or user existence is the problem

5. You want to grant a service account named deploy-bot in namespace dev permission to create pods across all namespaces. Which is the correct approach?

hard

A. Create a RoleBinding in each namespace binding deploy-bot to a Role with pod creation rights.

B. Create a RoleBinding in the dev namespace binding deploy-bot to a Role with pod creation rights.

C. Create a ClusterRoleBinding binding the deploy-bot service account to a ClusterRole with pod creation rights.

D. Create a ClusterRole with pod creation rights but no binding is needed.

Solution

1. Step 1: Identify scope needed

   Permission to create pods across all namespaces requires cluster-wide scope.

2. Step 2: Choose correct binding type

   A ClusterRoleBinding is needed to bind the deploy-bot service account to a ClusterRole with pod creation rights cluster-wide.

3. Final Answer:

   Create a ClusterRoleBinding for deploy-bot to a ClusterRole with pod creation rights. -> Option C

4. Quick Check:

   ClusterRoleBinding = cluster-wide permissions [OK]

Hint: ClusterRoleBinding for cluster-wide access to service accounts [OK]

Common Mistakes:

• Using RoleBinding for cluster-wide permissions
• Not creating any binding after ClusterRole
• Creating RoleBinding in only one namespace