What is RBAC in Kubernetes?

RBAC stands for Role-Based Access Control. It is an approach that is used for restricting access to users and applications on the system/network. RBAC is used by Kubernetes for authorization, for example giving access to a user, adding/removing permissions and setting up rules, etc. So basically, it adds security to a Kubernetes cluster. RBAC in Kubernetes is the way that you restrict who can access what within the cluster.

Why RBAC?

Let’s see why you’re interested in Access Control. Well obviously, you have multiple people on your teams and they’re accessing your Kubernetes cluster. Each of them needs to have some amount of security from one another. 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.

When you think about the differences between developers and operators cluster administrators, it becomes even more clear that there are different capabilities that they need to be associated with different types of roles within a Kubernetes cluster. That is where the notion of RBAC or Role-Based Access Control comes into play.

RBAC schema model

RBAC got introduced from Kubernetes 1.8, it uses rbac.authorization.k8s.io API group for creating authorization policies. To enable RBAC manually for a Kubernetes cluster you need to start the cluster with the flag — authorization-mode=RBAC

By default, RBAC is enabled in Kubernetes. RBAC in Kubernetes infrastructure is implemented through Role, ClusterRole, RoleBinding, and ClusterRoleBinding. Let me tell you what they are with examples.

Role

Role in Kubernetes Role-Based Access Control defines a notion of a verb like get or list and a set of nouns like pod volumes etc. So, a role defines what you can do to a set of resources. It contains a set of rules which define a set of permission.

I encourage people to check out all the different roles that are predefined inside of Kubernetes. There’s a lot of them that can give you an idea and you can even use to build up your own sort of access control and take a deep look into how you want to manage the different roles inside of your cluster so that you can provide a secure cluster where to developers or two operators can’t step on each other’s toes see each other’s Secrets or otherwise interfere with one another.

Here is a simple example for Roles, where the user has permission to just get and list the pods:

ClusterRole

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.

Below YAML code defines ClusterRole which grants all then permission to cluster-admin.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
    annotations:
       rbac.authorization.kubernetes.io/autoupdate: “true”
       creationTimestamp: null
       labels:
         kubernetes.io/bootstrapping: rbac-defaults
         name: cluster-admin
  rules:
      - apiGroups:
      - ‘*’
      resources:
       - ‘*’
       verbs:
       - ‘*’

RoleBinding

RoleBinding is used for granting permission to a Subject in a Kubernetes cluster. Subjects are nothing but a set of users, services or groups trying to access Kubernetes API. It defines what operations a user, service or group can perform. It provides privileges within the context of a particular namespace.

Below is an example of RoleBinding where roleRef is being used to bind user John with the role I created above — ElasticSearch.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
    name: elasticsearch
roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: elasticsearch
subjects:
- kind: User
  name: John
  namespace: default

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.

Below is an example of ClusterRoleBinding where roleRef is being used to bind group masters with the ClusterRole I created above — cluster-admin.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
   name: cluster-admin
roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
subjects:
 - apiGroup: rbac.authorization.k8s.io
   kind: Group
   name: masters

­­

The main idea behind Role-Based Access Control is to provide access to resources to those users who require and deny access to resources from users who do not require it. This increases security in a Kubernetes Infrastructure.

If you have any question or need a specific consultancy about Kubernetes, I’m available at contact@danielckv.com (https://danielckv.com)