Kubernetes and Cloud Native Associate (KCNA)Cloud Native SecurityMedium
A security auditor is reviewing the configuration of a Kubernetes cluster and observes that application Pods are granted broad permissions to interact with the Kubernetes API, including the ability to create and delete deployments in their namespace. To adhere to the principle of least privilege, which Kubernetes RBAC resource should be used in conjunction with a ServiceAccount to restrict these permissions to only what is strictly necessary for the application?
- ASecret
- BRoleBinding
- CConfigMap
- DClusterRole
Show answer & explanationAnswer & explanation
Correct answer: B. RoleBinding
A Role defines a set of permissions within a namespace, and a RoleBinding grants those permissions to a ServiceAccount (or user/group). By creating a specific Role with minimal permissions and binding it to the application's ServiceAccount, the principle of least privilege is enforced.
Why the other options are wrong
- A. A Secret stores sensitive data, not RBAC permissions.
- C. A ConfigMap stores non-sensitive configuration data, not RBAC permissions.
- D. A ClusterRole defines permissions across the entire cluster, but it's the RoleBinding that applies it to a specific ServiceAccount.
Kubernetes Role-Based Access Control (RBAC)
A method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In Kubernetes, it uses Roles/ClusterRoles and RoleBindings/ClusterRoleBindings to grant permissions.
- Uses Roles to define permissions.
- Uses RoleBindings to grant Roles to subjects (users, service accounts).
- Enforces least privilege by granting only necessary access.
Memory trick: ServiceAccount is 'who', Role is 'what', RoleBinding is 'how they connect'.