Table of contents
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.