Pregunta de Kubernetes Security #019e3a4f

Summary

Role Based Access Control (RBAC) is the Kubernetes authorization mode that provides granular control over operations that different entities (users, groups, service accounts) can perform on different objects (pods, services, secrets, etc.) in a cluster. RBAC uses roles and role bindings to define permissions, allowing administrators to specify exactly which actions (get, list, create, update, delete, etc.) are allowed on which resources.

How it Works

RBAC works by defining Role or ClusterRole objects that contain sets of rules (verbs and resources). These roles are then bound to subjects (users, groups, or service accounts) via RoleBinding or ClusterRoleBinding objects. For example, a Role can grant get, list, and watch permissions on pods in a specific namespace, and a RoleBinding can assign that role to a user. This allows fine-grained, namespace-scoped or cluster-scoped access control.

Why the Correct Answer is Right

Role Based Access Control is the correct answer because it is specifically designed for granular, role-based permissions in Kubernetes. It is the most commonly used authorization mode for production clusters, offering flexibility and precision. RBAC is enabled by starting the API server with --authorization-mode=RBAC and is configured via YAML manifests.

Why the Incorrect Answers are Wrong

• Webhook Mode Authorization Control: This mode delegates authorization decisions to an external HTTP(S) service. While it can be granular, it is not a built-in mechanism for defining permissions within Kubernetes; it relies on an external system. It is typically used for custom or third-party authorization logic.
• Node Authorization Access Control: This is a special-purpose authorizer that grants permissions to kubelets based on their node identity. It is not designed for general user or service account access control and does not provide granular control over different objects for different entities.
• Attribute Based Access Control (ABAC): ABAC uses policies defined in a JSON file to grant access based on attributes (user, group, resource, etc.). While it can be granular, it is less flexible and harder to manage than RBAC. ABAC policies are static and require editing a file and restarting the API server, whereas RBAC is dynamic and managed via the Kubernetes API. ABAC is considered legacy and is not recommended for new deployments.