What is RBAC?

RBAC is Role Based Access Control which provides required access permission to users or service accounts. It is directly related to security.

RBAC is a simple topic to understand but complicates things when not done right. So, gaining theoretical knowledge will help you through the entire process of RBAC.

There are two sectors where RBAC comes in handy:

• USERS

• SERVICE ACCOUNTS

USERS

Let us take an example of minikube cluster where we get admin control. Here we can modulate anything and there is no threat as minikube is used for practice purposes. But in organizations, we cannot provide admin privileges to every team. This will lead to anyone accessing and deleting the clusters or vital information.

Suppose in an organization there is a QE user and a DEV user. Appropriate rules and permissions should be provided to those users so they can only access the services they need to perform.

So RBAC provides appropriate rules and permissions for users in an organization.

SERVICE ACCOUNTS

Similar to users, RBAC also provides rules and permissions using service accounts for PODS in k8s.

Suppose there is a malicious pod that is deleting the API server as it has all the rules and permissions. This is a direct threat to the security of the services provided by the organization.

To control the security threat, RBAC comes into handy for providing roles and access privileges to those service accounts.

RBAC IN KUBERNETES

Kubernetes itself does not look after security. So, we need RBAC or other extra components to secure the cluster.

In kubernetes we have three major things for managing the roles:

• Users/ Service accounts

• Roles/ Cluster Roles

• Role binding/ Cluster role binding

FOR USERS:

As Kubernetes does not provide a facility for making users, it is offloaded to identity providers like LDAP, Keycloak, etc.

Suppose we have EKS cluster. We can create IAM oAuth provider and use the same user and group in EKS cluster.

We can use EKS and connect with Keycloak and connect with github.

This way EKS cluster can use Github users.

FOR SERVICE ACCOUNTS:

In pods, Kubernetes creates a default service account that talks with the API server. We can also create our service account and assign it to the pods.

ROLES/CLUSTER ROLES

ROLES are created which are like policies in AWS. These are the permissions and rules that the User/ServiceAccount should follow. These roles are assigned to the users by using Role Binding. If the roles are defined for a cluster it is known as cluster roles.

EXAMPLE: Role --> access to the pod, config map, secrets

ROLE BINDING/CLUSTER ROLE BINDING

For the connection between users/service accounts with the created roles, we use role binding/cluster role binding.

Cluster binding permissions are set for the whole cluster (every namespace).

Simple role binding sets rules for a particular namespace.