RBAC to Manage Kubernetes

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

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. 

Authorization

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.

Admission Control

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.

Subjects

Traditionally, subjects in RBAC rules are users, groups, or service accounts.

Aggregated ClusterRoles

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 "kelly@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.

Auto-reconciliation

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.

To Conclude

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.