RBAC is an acronym for Role-Based Access Control. You can restrict users and applications to certain areas of the system or network using this approach. Access to valuable resources can be restricted based on a user's role when using role-based access control.
Control of access to network resources by role-based access control (RBAC) is determined by the roles of individual users within the organization. For example, an individual user's access refers to his or her ability to perform specified tasks, such as creating, reading, or editing a file.
Using this approach, IT administrators can create more granular security controls, but they must follow certain processes so they do not unintentionally create a cumbersome system.
For proper implementation of Kubernetes RBAC, the following approaches are recommended:
- Enforce the principle of least privilege: RBAC disables all access by default. Administrators determine user privileges at a finer level. Ensure you only grant the necessities to users; granting additional permissions can pose a security risk and increase attack surfaces.
- Continually adjust your RBAC strategy: RBAC rules and roles are not autonomous - IT teams cannot simply put RBAC policies and walk away. Validating RBAC at a slow pace is the best approach. If a satisfactory state cannot be reached, implement RBAC in phases.
- Create fewer roles and reuse existing ones. The purpose of RBAC permissions should not be defeated by customizing Kubernetes roles to suit individual user needs. In RBAC, roles are used rather than users as the determining factor. Identical permissions should be assigned to groups of users, and roles should be reusable. It simplifies role assignments for existing roles, enhancing the efficiency of the role assignment process.
Authentication and Authorization in RBAC
Authentication occurs after the TLS connection has been established. This is the first step. Next, API servers are configured to run one or more Authenticator Modules by the cluster creation script or cluster admin. Passwords, Plain Tokens, and Client certificates are included in the authentication modules.
Users in Kubernetes
Users in Kubernetes clusters typically fall into two categories: service accounts that Kubernetes manages and normal users.
Authorizing the request should follow after verifying that it is coming from the selected user. The request must indicate the user's name, the action requested, and the object affected by the request. If the user is authorized to perform the requested action by a policy, then the request is approved.
Modules for modifying or rejecting admission requests are known as Admission Control Modules. Admission Controller Modules can access the contents of the object being created or modified in addition to all the attributes that are available to Authorization Modules. Admission controller modules reject requests instantly, unlike authentication and authorization modules.
Role In RBAC
The role you assume in Kubernetes RBAC determines which resources you will access, manage and change. The Kubernetes RBAC model consists of three main components: subjects, roles and rolebindings:
Role and ClusterRoles
This set of permissions defines how permissions can be accessed. Roles govern permissions at the namespace level, while ClusterRoles govern permissions at the cluster level or for all namespaces within a cluster.
RoleBinding and ClusterRoleBinding.
Subjects are listed according to their groups and service accounts, and their associated roles are outlined. There are three types of role bindings: roles, ClusterRoles, and ClusterRoleBindings. RoleBindings bind roles; ClusterRoles manage permissions on namespaced resources and ClusterRoleBindings bind ClusterRoles to namespaces.
Traditionally, subjects in RBAC rules are users, groups, or service accounts.
Combining several ClusterRoles is possible. ClusterRole objects with aggregate rules are monitored by a controller that runs within the cluster control plane. The rules field of this object provides a label selector that the controller can use to combine other ClusterRole objects.
Referring to subjects
Subjects and roles are bound by RoleBindings or ClusterRoleBindings. Groups, users, and ServiceAccounts are all valid subjects.
A username in Kubernetes is represented as a string. It might be a plain name such as "Ruth," an email name such as "email@example.com"; or a string of numbers representing the user's ID. Configuring authentication modules to produce usernames in the format you want is up to you as a cluster administrator.
Role bindings and default roles
API servers often create ClusterRoleBinding and ClusterRoles objects by default. The control plane manages many of these resources directly, as they are system: prefixed.
Each time the API server starts, missing permissions and missing subjects are added to the default cluster roles. As subjects and permissions change in Kubernetes releases, it allows the cluster to fix accidental modifications.
RBAC authorizers enable auto-reconciliation by default. Default cluster roles or role bindings can be set to false, preventing internal reconciliation. It is important to remember that clusters can become unusable when subjects and default permissions are missing.
Kubernetes implementation across organizations is at an all-time high. It is mission-critical, and it demands strict security and compliance rules and measures. By defining which types of actions are allowed for each user based on their role within your organization, you can ensure that your cluster is managed correctly.