DevNet Associate (DEVASC) v1.0Application Deployment and SecurityMedium
A DevOps team is setting up a Kubernetes cluster and needs to implement role-based access control (RBAC) for their developers. They want to define roles that grant specific permissions within a single namespace, such as deploying pods or viewing logs, but not cluster-wide administrative privileges. Which Kubernetes RBAC object should they use to define these namespace-scoped permissions?
- ARole
- BClusterRoleBinding
- CRoleBinding
- DClusterRole
Show answer & explanationAnswer & explanation
Correct answer: A. Role
A Kubernetes Role is used to define a set of permissions within a specific namespace. This aligns with the requirement of granting namespace-scoped permissions without affecting other namespaces or providing cluster-wide access.
Why the other options are wrong
- B. ClusterRoleBinding grants cluster-wide roles to users or groups, which is too broad.
- C. RoleBinding attaches a Role (or ClusterRole) to users/groups/service accounts within a specific namespace; it doesn't define the permissions itself.
- D. ClusterRole defines permissions that apply across the entire cluster, not within a single namespace.
Kubernetes Role
A Kubernetes RBAC object that defines a set of permissions within a specific namespace. It specifies allowed verbs (actions) on resources (e.g., pods, deployments) within that namespace.
- Namespace-scoped permissions.
- Defines allowed actions on resources.
- Bound to users/groups/service accounts via RoleBinding.
Memory trick: Roles define permissions, Bindings assign them; Cluster for global, Role for namespace.