Role-Based Access Control (RBAC) is a security mechanism in which each access authorization is based on roles that are assigned to a user. With this system, it is, therefore, possible to restrict access to the resources of a Kubernetes cluster (namespaces, pods, jobs) to applications or users.
In Kubernetes, RBAC policies can be used to manage the access rights of a system user (User or Group) as well as those of service accounts (Service Account).
There are other ways to authorize users in Kubernetes such as ABAC (Attribute-based access control), through Webhook or Node Authorization, but the most widely used and native authorization mechanism available in stable version is RBAC.
All interaction with the resources is done through the K8s API server, which means that, in the end, everything is limited to making HTTP requests to the said server (an essential component of the master node/s or Control Panel).
Kubernetes has four RBAC -related objects that can be combined to set cluster resource access permissions. These are Role, ClusterRole, RoleBinding, and ClusterRoleBinding. To work with these objects, like all Kubernetes objects, the Kubernetes API must be used.
Roles in Kubernetes
In Kubernetes, there are two types of roles called Role and ClusterRole. The biggest difference between the two is that the Role belongs to a concrete namespace, while the ClusterRole is global to the cluster. So, in the case of ClusterRole, its name must be unique since it belongs to the cluster. In the case of Role, two different namespaces can have a Role with the same name.
Another difference is that Role allows access to resources that are within the same namespace, while ClusterRole, in addition to being able to give access to resources in any namespace, can also give access to resources in the same namespace such as nodes among others.
To sign in we can utilise User Accounts, Service Accounts, and Groups. User accounts are accounts assigned to a particular user, while service accounts are used by processes. For example, imagine that our application needs to programmatically access resources from the cluster, for this we would use a service account.
Finally, we need the “glue” that binds a role to an account (user or service) or group. There are two resources in Kubernetes for this: RoleBinding and ClusterRoleBinding. RoleBinding can reference a role that is in the same namespace, while the ClusterRoleBinding can reference any Role in any namespace and assign permissions globally.
As a note, the permissions only allow access to resources, because “by default, everything is denied” and it is possible to assign several roles to the same user
The only pre-requisite for using RBAC is that it is enabled on our cluster using the “–authorization-mode=RBAC” option.
What are risky RBAC permissions and how to fix them?
Any permission that allows or can allow unauthorized access to the pod resources is considered risky permission. For example, if a user has edit permission, they can edit their own Role and can access resources that they are not otherwise allowed to access. This can result in a compliance issue. Similarly, if old permissions are left unchecked then some users can access resources they no longer need.
It is difficult and time-consuming to manually find such risky permission when you have a large number of Roles. To make this process easier there are a number of RBAC permissions audit tools that help to scan your whole Cluster to locate any risky permissions. It’s also important to understand that the effectiveness of RBAC depends on an up to date RBAC policy that in turn requires regular permission auditing.
