Role-based Access Control (RBAC) to Strengthen Kubernetes Security!
Today enterprises are adopting modernization of their application stack using Microservices architecture and extending all capabilities of Kubernetes containerization to further strengthen their digital transformation journeys.
Kubernetes is by far the most widely used container orchestrator in the market, and Kubernetes adoption — especially in production environments — is taking off. According to Gartner, “by 2022, more than 75% of global organizations will be running containerized applications in production.”
When it comes to containerization and orchestration for enterprises the explosion in kubernetes adoption hasn’t been without it share security concerns. Enterprises cannot afford to leave security concerns unattended and uncovered as an afterthought.
Role Based Access Control (RBAC) on kubernetes makes a total sense for enterprises to consider which designing their architecture. It is so obvious that enterprises wanted to control their security access policies to a cluster. RBAC is an approach that is widely used for restricting access to users and applications on the system/network.
Why RBAC?
To understand RBAC better, let’s take an example where you have a HR application which support user name and password. Every user who has a valid user credentials can access the system with all the modules with full control/privileges to read/update/delete etc. there is no difference between an admin and a normal end user. If HR application is further strengthen with Role based access, which means a user is mapped to a particular role as defined by his department, he shall not be able to access rest of the modules and avoid security breaches. Admin user will be the one who will have full control and can modify any required model as per business needs.
Similar to the above application, similar scenario is applicable to Kubernetes cluster as well. Where, it is so obvious that enterprise has a dedicated team who manages the Kubernetes cluster and worker nodes who will be accessing the Kubernetes often. Each of them should have some amount of security guided principal inheritance which will differentiate each of them from others. There could be cases, where a member in your team is interfering with the other members, work accidentally, for example, one developer might accidentally delete someone else’s work or gain visibility into a secret project that’s being developed. In such cases, having Role-Based Access Control is mandatory.
Developer needs to only have a specific access on worker nodes as compared to operation member who need to have an access on Master & Worker nodes both. It becomes evident that different capabilities need to associated with different set of users. That is where the concept of Kubernetes RBAC comes into play.
RBAC in Kubernetes is based on three key concepts:
1) Verbs: verbs are the set of operations that can be executed on resources living on Kubernetes cluster. There are many verbs, but they’re all Create, Read, Update or Delete (also known as CRUD)
2) API Resources: they are the objects available on the cluster. They are the Pods, service, nodes, PersistentVolumes, etc
3) Subjects: these are the objects (users, groups, processes) allowed access to the API Resources based on the verbs defined
All these three components combined together in kubernetes enables enterprises to have security concerns address.
There are two type of users in kubernetes, service accounts which are managed by kubernetes and a normal user. These normal users are part of standard identity providers available with enterprise.
Here is a kubectl command which can be used to create a service account:
kubectl create serviceaccount appviewerClusterRole
Roles are used to assigning resources for a namespace, but if you need to assign resources on a cluster level, you need to use ClusterRole. It is similar to Roles, but it can grant permissions that are cluster-scoped such as giving resource permissions across all namespaces in the cluster.
ClusterRoles have several uses. You can use a ClusterRole to:
· define permissions on namespaced resources and be granted within individual namespace(s)
· define permissions on namespaced resources and be granted across all namespaces
· define permissions on cluster-scoped resources
Next we create cluster role to enable access to a particular resources and api references:
kubectl create clusterrole appviewer-role --verb=list,get,create --resource=pods --namespace=production-web
ClusterRoleBinding
ClusterRoleBinding is used to grant permission to a subject on a cluster-level in all the namespaces.
It can provide you with permissions for cluster resources and it can also provide you with permissions for resources within any namespace within a cluster. Obviously clusterRoleBindings are very powerful and you want to be careful with how you apply them because they apply not only to any existing namespaces but to any future namespaces that you might create as well.
Next we create cluster role binding to bind a created cluster role with serviceaccount
kubectl create clusterrolebinding appviewer-role-binding --clusterrole=appviewer-role --namespace=production-web --serviceaccount=production-web:appviewer
Similarly, we can create normal users and can create role and rolebindings association.
principle of least privilege (POLP), an important concept in computer security, is the practice of limiting access rights for users to the bare minimum permissions they need to perform their work.
Conclusion:
Role Based Access Control best practices ensures that the access has been granted at least privileges and in controlled manner. No one has access to everything and then break things. RBAC controls to allow a user to grant privileges to others, but not more than he possesses himself.
