Kubernetes and Cloud Native Associate (KCNA)Cloud Native SecurityMedium
A platform team is configuring Role-Based Access Control (RBAC) for a new developer team in a Kubernetes cluster. The new team needs to be able to create, view, update, and delete (CRUD) Pods, Deployments, and Services within their designated namespace, 'dev-team-a', but should not be able to manage cluster-wide resources or modify RBAC roles themselves. Which Kubernetes RBAC object should be primarily used to grant these permissions?
- AClusterRoleBinding
- BClusterRole
- CServiceAccount
- DRole
Show answer & explanationAnswer & explanation
Correct answer: D. Role
A 'Role' is a namespaced RBAC object that defines a set of permissions within a specific namespace. Since the developer team's permissions are restricted to their 'dev-team-a' namespace for specific resource types (Pods, Deployments, Services), a Role is the appropriate object to define these permissions.
Why the other options are wrong
- A. ClusterRoleBinding binds a ClusterRole to a user/group/ServiceAccount, granting cluster-wide permissions, which is not desired here.
- B. ClusterRole defines permissions across the entire cluster, which is too broad for this requirement.
- C. ServiceAccount represents an identity for processes running in pods, not a set of permissions.
Kubernetes Role (RBAC)
A namespaced Kubernetes RBAC object that defines permissions (verbs) on resources within a specific namespace.
- Defines permissions (e.g., get, list, create, update, delete).
- Applies to specific resources (e.g., pods, deployments).
- Scoped to a single namespace.
- Bound to users/groups/ServiceAccounts via RoleBinding.
Memory trick: Roles define what, Bindings define who, Scope matters.