However, if it is not used properly, it can easily cause a compliance catastrophe. That’s why we need RBAC tools to audit and locate risky permissions in Kubernetes. In this article, we will discuss what Kubernetes RBAC is, why it’s important to audit risky permissions, and discover the tools that can help us best in auditing risky permissions!
What is RBAC?
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 the stable version is RBAC. Practically all interaction with the resources is done through its 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 a Role, two different namespaces can have a Role with the same name. Another difference that should be mentioned 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. Now that we know the types of roles, the next thing is to know to who we can assign these roles. In this case, we have 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. We can check this using the command:
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 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. Following are some of the best RBAC tools to audit permissions based on different languages and user interfaces.
KubiScan
KubiScan is a Python-based RBAC tool for scanning risky permissions in a Kubernetes cluster. The tool has to be executed within the Master node and then it can be run directly from the terminal to give a list of risky permissions. Kubiscan can be used to find risky Roles, ClusterRoles, RoleBindings, ClusterBindings, Subjects, Pods, and even Containers.
Krane
Krane by Appvia is a Ruby-based Kubernetes RBAC static analysis and visualization tool. It can be run both locally as a CLI or in a CI/CD pipeline. Moreover, it can also work as a standalone service within a Kubernetes container. Krane gives the feature to analyze RBAC permissions through faceted tree and graph network views. It also gives alerts for any risky permissions through its Slack integration.
RBAC Tool
RBAC Tool by InsightCloudSec is a standalone permission auditing tool built with Go. It does not just allow you to scan and highlight risky RBAC permissions but it also lets you generate RBAC policy from permissions audit through its Auditgen feature. RBAC tool also offers the feature of RBAC visualization.
Fairwinds
Fairwinds Insight is a standalone tool that provides a number of Kubernetes security and compliance features. Its policy enforcement feature allows you to audit RBAC permissions and scan them against standard and customized policies. Fairwinds offers an on-demand demo.
Permission Manager
Permission Manager by Signup is a Javascript-based Kubernetes permission management tool. It offers an easy and initiative way to manage user permissions within a Kubernetes cluster. Permission Manager also offers an enterprise edition of the tool which allows you to do basic RBAC permission auditing.
Conclusion 👩💻
Kubernetes RBAC is an efficient way to manage access to resources in a Kubernetes cluster. However, if not implemented properly it can lead to security and compliance issues. This, however, can be avoided by continuously auditing permissions through RBAC auditing tools. You may also be interested in Kubernetes Best Practices.
