Roles and ClusterRoles in Kubernetes - Mini Project: Build & Apply

Roles and ClusterRoles

📖 Scenario: You are managing access permissions in a Kubernetes cluster for a small team. You need to create specific permissions for users to control resources within a namespace and across the whole cluster.

🎯 Goal: Learn how to create a Role for namespace-specific permissions and a ClusterRole for cluster-wide permissions in Kubernetes.

📋 What You'll Learn

Create a Role YAML manifest with specific permissions in a namespace

Create a ClusterRole YAML manifest with cluster-wide permissions

Understand the difference between Role and ClusterRole

Use correct Kubernetes API syntax for Roles and ClusterRoles

💡 Why This Matters

🌍 Real World

In real Kubernetes clusters, controlling who can do what is critical for security and smooth operations. Roles and ClusterRoles help define these permissions clearly.

💼 Career

Understanding Roles and ClusterRoles is essential for Kubernetes administrators, DevOps engineers, and anyone managing cloud-native applications securely.

1

Create a Role YAML manifest

Create a YAML manifest named role.yaml that defines a Role called pod-reader in the development namespace. This Role should allow get, watch, and list actions on the resource pods.

Kubernetes

# Create a Role named pod-reader in the development namespace with get, watch, list permissions on pods
# Your code here

Hint

Remember to specify kind: Role, the metadata.namespace, and the rules with correct resources and verbs.

2

Create a ClusterRole YAML manifest

Create a YAML manifest named clusterrole.yaml that defines a ClusterRole called node-reader. This ClusterRole should allow get, watch, and list actions on the resource nodes across the entire cluster.

Kubernetes

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

# Create a ClusterRole named node-reader with get, watch, list permissions on nodes
# Your code here

Hint

Use kind: ClusterRole and do not specify a namespace because ClusterRoles are cluster-wide.

3

Bind the Role to a user in the namespace

Create a YAML manifest named rolebinding.yaml that binds the pod-reader Role in the development namespace to a user named alice. Use RoleBinding kind.

Kubernetes

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

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

# Create a RoleBinding named read-pods-binding in development namespace binding pod-reader Role to user alice
# Your code here

Hint

Use RoleBinding with subjects specifying the user and roleRef pointing to the Role.

4

Bind the ClusterRole to a user cluster-wide

Create a YAML manifest named clusterrolebinding.yaml that binds the node-reader ClusterRole to a user named bob across the entire cluster. Use ClusterRoleBinding kind.

Kubernetes

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

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

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

# Create a ClusterRoleBinding named read-nodes-binding binding node-reader ClusterRole to user bob
# Your code here

Hint

Use ClusterRoleBinding with subjects specifying the user and roleRef pointing to the ClusterRole. No namespace is needed.

Practice

1. What is the main difference between a Role and a ClusterRole in Kubernetes?

easy

A. Role applies permissions within a single namespace, ClusterRole applies cluster-wide.

B. Role applies cluster-wide, ClusterRole applies within a single namespace.

C. Role is for users, ClusterRole is for service accounts only.

D. Role manages nodes, ClusterRole manages pods.

Solution

1. Step 1: Understand Role scope

   A Role defines permissions limited to a specific namespace in Kubernetes.

2. Step 2: Understand ClusterRole scope

   A ClusterRole defines permissions that can apply across all namespaces or cluster-wide resources.

3. Final Answer:

   Role applies permissions within a single namespace, ClusterRole applies cluster-wide. -> Option A

4. Quick Check:

   Role = namespace, ClusterRole = cluster-wide [OK]

Hint: Role = namespace only, ClusterRole = whole cluster [OK]

Common Mistakes:

• Confusing Role and ClusterRole scopes
• Thinking ClusterRole is only for nodes
• Assuming Role applies cluster-wide

2. Which of the following is the correct YAML snippet to create a Role that allows reading pods in a namespace?

easy

A. apiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n name: pod-reader\nrules:\n- apiGroups: ['']\n resources: ['pods']\n verbs: ['get', 'watch', 'list']

B. apiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n name: pod-reader\nrules:\n- apiGroups: ['']\n resources: ['pods']\n verbs: ['create', 'delete']

C. apiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n name: pod-reader-binding\nroleRef:\n kind: Role\n name: pod-reader\nsubjects:\n- kind: User\n name: alice

D. apiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n name: pod-reader\nrules:\n- apiGroups: ['apps']\n resources: ['pods']\n verbs: ['get', 'watch', 'list']

Solution

1. Step 1: Check kind and apiVersion

   The resource is a Role with apiVersion rbac.authorization.k8s.io/v1, which is correct for RBAC.

2. Step 2: Verify rules for reading pods

   Pods are in the core API group (empty string), and verbs for reading are get, watch, and list. apiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n name: pod-reader\nrules:\n- apiGroups: ['']\n resources: ['pods']\n verbs: ['get', 'watch', 'list'] matches this exactly.

3. Final Answer:

   The YAML snippet with kind: Role, apiGroups: [''], resources: ['pods'], verbs: ['get', 'watch', 'list']. -> Option A

4. Quick Check:

   Role + core API + read verbs = apiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n name: pod-reader\nrules:\n- apiGroups: ['']\n resources: ['pods']\n verbs: ['get', 'watch', 'list'] [OK]

Hint: Role for namespace, core API group is empty string [''] [OK]

Common Mistakes:

• Using ClusterRole instead of Role for namespace scope
• Wrong apiGroups value like 'apps' for pods
• Confusing RoleBinding with Role definition

3. Given this RoleBinding YAML snippet, what namespace will the binding apply to?

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

medium

A. default namespace

B. Cluster-wide

C. kube-system namespace

D. dev namespace

Solution

1. Step 1: Check metadata namespace in RoleBinding

   The RoleBinding has namespace: dev in its metadata, so it applies in the 'dev' namespace.

2. Step 2: Understand RoleBinding scope

   RoleBindings are namespace-scoped, so they only apply in the namespace where they are created.

3. Final Answer:

   The RoleBinding applies to the dev namespace. -> Option D

4. Quick Check:

   RoleBinding namespace = binding scope [OK]

Hint: RoleBinding namespace field sets scope [OK]

Common Mistakes:

• Assuming RoleBinding applies cluster-wide
• Confusing RoleBinding with ClusterRoleBinding
• Ignoring the metadata namespace field

4. You created a ClusterRoleBinding but users report they cannot access cluster resources. Which is the most likely mistake?

medium

A. The subjects field is missing the user names.

B. The roleRef kind is set to Role instead of ClusterRole.

C. The ClusterRoleBinding is created in a namespace.

D. The apiVersion is set to v1 instead of rbac.authorization.k8s.io/v1.

Solution

1. Step 1: Check roleRef kind for ClusterRoleBinding

   A ClusterRoleBinding must reference a ClusterRole in its roleRef.kind. Using Role is invalid and prevents access.

2. Step 2: Verify other fields

   While missing subjects or wrong apiVersion cause issues, the most common cause is wrong roleRef.kind. ClusterRoleBindings are cluster-scoped and do not belong to namespaces.

3. Final Answer:

   The roleRef kind must be ClusterRole, not Role. -> Option B

4. Quick Check:

   ClusterRoleBinding needs ClusterRole in roleRef [OK]

Hint: ClusterRoleBinding must reference ClusterRole kind [OK]

Common Mistakes:

• Using Role instead of ClusterRole in roleRef
• Creating ClusterRoleBinding in a namespace
• Forgetting to specify subjects

5. You want to allow a user to list pods in all namespaces but only create pods in the 'test' namespace. Which combination of Kubernetes RBAC objects should you create?

hard

A. A ClusterRoleBinding granting create pods cluster-wide.

B. A single Role with both permissions in the 'test' namespace.

C. A ClusterRole with list pods permission and a Role with create pods permission, plus respective bindings.

D. A RoleBinding in 'test' namespace granting list and create pods.

Solution

1. Step 1: Understand permission scopes

   Listing pods in all namespaces requires a ClusterRole because it is cluster-wide permission.

2. Step 2: Restrict create pods to 'test' namespace

   Creating pods only in 'test' namespace requires a Role scoped to that namespace.

3. Step 3: Bind roles to user

   Use a ClusterRoleBinding for the cluster-wide list permission and a RoleBinding for the create permission in 'test'.

4. Final Answer:

   Create a ClusterRole for list pods and a Role for create pods with bindings. -> Option C

5. Quick Check:

   ClusterRole = cluster-wide, Role = namespace [OK]

Hint: Use ClusterRole for cluster-wide, Role for namespace-specific [OK]

Common Mistakes:

• Trying to use a single Role for cluster-wide permissions
• Using ClusterRoleBinding for namespace-only permissions
• Not creating separate bindings for each role