Roles and ClusterRoles in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Difference between Role and ClusterRole

Which statement correctly describes the difference between a Role and a ClusterRole in Kubernetes?

A Both Role and ClusterRole define permissions cluster-wide.

B A Role defines permissions cluster-wide, while a ClusterRole defines permissions within a specific namespace.

C Both Role and ClusterRole define permissions only within a specific namespace.

D A Role defines permissions within a specific namespace, while a ClusterRole defines permissions cluster-wide.

💡 Hint

Think about the scope where each permission applies.

A Role is limited to a namespace and cannot grant permissions outside it. A ClusterRole can grant permissions across all namespaces or cluster-wide resources.

💻 Command Output

intermediate

kubectl command output for ClusterRole listing

What is the output of the command kubectl get clusterroles in a default Kubernetes cluster?

Kubernetes

kubectl get clusterroles

A A list of all ClusterRoles including default ones like 'admin', 'edit', and 'view'.

B A list of Roles limited to the current namespace.

C An error stating 'clusterroles' resource not found.

D No output because ClusterRoles are not created by default.

💡 Hint

ClusterRoles are cluster-wide and many default ones exist.

The command lists all ClusterRoles in the cluster, including default roles like 'admin', 'edit', and 'view'.

❓ Configuration

advanced

YAML for Role with Pod read permissions

Which YAML snippet correctly defines a Role named pod-reader that allows reading pods only in the development namespace?

A

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

B

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

C

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

D

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

💡 Hint

Remember Roles are namespace-scoped and need the namespace field.

Option A correctly defines a Role scoped to the 'development' namespace with permissions to read pods.

❓ Troubleshoot

advanced

Why does a RoleBinding fail to grant permissions?

You created a RoleBinding in the production namespace that references a ClusterRole named view. The user still cannot list pods in production. What is the most likely cause?

A RoleBindings can only reference Roles, not ClusterRoles.

B RoleBindings can reference ClusterRoles, but the ClusterRole must have namespace-scoped rules.

C The RoleBinding must be created in the same namespace as the user.

D The RoleBinding must be a ClusterRoleBinding to reference a ClusterRole.

💡 Hint

Think about how ClusterRoles and RoleBindings interact with namespaces.

RoleBindings can reference ClusterRoles, but the ClusterRole must include rules that apply to the namespace of the RoleBinding. If the ClusterRole only has cluster-scoped rules, it won't grant permissions in the namespace.

✅ Best Practice

expert

Best practice for granting cluster-wide read access to nodes

You want to grant a service account read-only access to all nodes in the cluster. Which is the best approach?

A Create a ClusterRole with node read permissions and bind it to the service account with a RoleBinding in any namespace.

B Create a Role with node read permissions in the default namespace and bind it to the service account with a RoleBinding.

C Create a ClusterRole with node read permissions and bind it to the service account with a ClusterRoleBinding.

D Create a Role with node read permissions in each namespace and bind it to the service account with multiple RoleBindings.

💡 Hint

Consider the scope of nodes and how to grant cluster-wide permissions.

Nodes are cluster-scoped resources. To grant read access cluster-wide, use a ClusterRole and bind it with a ClusterRoleBinding to the service account.