Kubernetes Role-Based Access Controls (RBAC)

These objects are like roles and cluster roles. These roles and cluster roles are the object of which different sets of permissions within the cluster role. You can define the set of permissions that you are going to allow for that particular cluster role and on which object that permission will be applicable. Similarly, in the role, you can define a set of permissions of which particular object that permission is going to allow. The role depends on the permission within the namespace. Basically, these roles are limited to a namespace level, whereas the cluster roles are not limited to the class or namespace level, they are applicable to the whole cluster.

Now, after creating these roles, we need to bind these roles to their particular user. For that, we have an object called role binding. Similarly, we use one more object to bind this role with the user called cluster binding which we use to bind the cluster roles to the particular user. Now, let us assume that we have a cluster and inside that cluster, we have a namespace. Within that namespace, we have a role and this role can be bound to a particular user using an object called role binding. Similarly, we have the cluster role. We can use this cluster role to bind the role to the particular user. Within this binding, you can use the role within the user. There is nothing more here you can bind. In this role binding, we don’t have any one-to-one relationship, we have many-to-many relationships. For example, we can attach a role to multiple users. Similarly, we can attach a single role to multiple users. We can attach multiple roles to a single user, as well. There is no one-to-one relationship in this role-based access.

For demonstrating this session, I have created a handy document. I’m going to execute this on a Kubernetes cluster. I have a minikube setup. I’m going to create namespaces now. The roles are limited to a namespace level. Now I’m going to create a namespace called a development on my minikube cluster. I have created a new namespace called development. Let us view this namespace using KubeCTL. There is a namespace created with the name of development. Now moving forward.

We need to follow a few steps before creating a user. For that, I’m going to change my directory to this .kube directory. I’m in this local directory. Now, I’m going to create a public key for this user called the dev user. Now I’m going to create a new public key for that user. I’m using this command to create a new user. Now I’m going to create and save the kube for this dev user. The CSR keys have been created.

Now I’m going to request an SSL certificate. On this SSL certificate, I have mentioned this dev user CSR, and I’m going to put this inside this minikube certificate and change this certificate to a dev user certificate. This certificate has been updated to this minikube certificate. This kubeconfig, we have a context for the minikube only. Here, the current context has minikubes and the current user is a minikube. Yet, we don’t have any qualitative users. Now, we are going to add a qualitative user using this command. I’m going to create a user on a minikube for the dev user. I’m going to specify the path for the dev user certificate and the client key. The users have been set.

Similarly, I’m going to update the config. On this config, I have updated the user name and the cluster and the namespace, and the user name. I’m going to update it. Now, I’m going to do this kubeconfig. Previously, there was no dev user and now we have the user called dev user in our config file. Similarly, we have created a context for the namespace called development and the context name is Dev user. Now, we are going to try to access the port using this dev user. Here, you can see that I haven’t mentioned any namespace yet, because we have updated the namespace in the context, as well. I’m going to try to get the port.

This user isn’t able to access their dev user key. For that, I’m going to change the permission. The file permissions have been changed. Let me try to access the pod. It says that access is forbidden. This means the dev user doesn’t have permission to view the pods. For that, now we are going to create a role for the particular user to access the pod. For that, I’m going to create a role called pod reader role. We’ll say this, I have a manifest file here. I’m going to copy this. In this manifest file, we have mentioned the API version and the kind.

We are going to create a role and in the metadata, we have defined the namespace and the name of the role we are going to create inside the resource type. We are going to have mentioned what resource we are going to provide access for pod and pod logs. We are going to describe what action we are going to give permission for. We are going to give permission to get, watch, list, and update the pod. Now I’m going to create this manifest and update this manifest file, podreaderrole.yaml. This pod reader role has been created. Now I’m going to list this role. KubeCTL get role, I find and select, and this role has been created.

To attach this role to a particular user, we are going to create a role binding. For that, I’m going to create and manifest choice for creating a role binding. In this file, we have mentioned the API version. In the client, we are going to create an object. This is going to be a role-binding object. Inside the metadata, we are going to describe the port, media role name, and namespace. In the subject, we are going to describe the user and the user name, and the API version. In the role reference, we have referred to their role name pod role reader. I’m going to create this role now. As you can see here, the role binding has been created now.

Let us try to access the port using this command. Previously, we were getting an access forbidden error, and now it shows that there is no resource found in this development namespace. We are going to try to create using the user called dev user. We are getting an access forbidden error because the dev user doesn’t have access to create the port. For now, I’m going to create a pod as an admin user in this namespace development. I’m going to get this port using this dev user. Now we are able to access this pod. This is how we are able to provide and restrict access using this role-based access control.