Role Based Access Controls

Role Based Access Controls

In this tutorial, we are going to discuss about role-based access controls in much more detail in Kubernetes. So how do we create a role?

We can create roles by creating a role object. So we create a role definition file with the API version set to rbac.authorization.K8s.io/v1 and kind said to Role.

We name the role developer as we are creating this role for developers and then we specify rules. Each rule has three sections apiGroups, resources, and verbs. The same things that we talked about in one of the previous tutorials.

apiVersion: rbac.authorization.k8s.io/v1 
kind: Role 
metadata:
   namespace: default
   name: developer
rules:
- apiGroups: [""] # "" indicates the core API group  
  resources: ["pods"]
  verbs: ["get", "list", "create", "update", "delete"]

For core group, You can leave the API group’s section as blank for any other group you specify the group name the resources that we want to give developers access to our PODs.

The actions that they can take are list, get, create, update and delete. Similarly to allow the developers to create ConfigMaps, then we add another rule to create ConfigMap. We can add multiple rules for a single role like below.

Role example
apiVersion: rbac.authorization.k8s.io/v1 
kind: Role 
metadata:
   namespace: default
   name: developer
rules:
- apiGroups: [""] # "" indicates the core API group  
  resources: ["pods"]
  verbs: ["get", "list", "create", "update", "delete"]
- apiGroups: [""] 
  resources: ["ConfigMap"]
  verbs: ["create"]

Now create the role using the kubectl create role command.

$ kubectl create -f developer-role.yaml

Now the next step is to link the user to that role. For this we create another object called RoleBinding. The role binding object links A user object to a role.

We will name it devuser-developer-binding.

RoleBinding example
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-developer-binding
  namespace: default
subjects:
- kind: User
  name: dev-user 
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role 
  name: developer
  apiGroup: rbac.authorization.k8s.io

Here The kind is RoleBinding. It has two sections. The subjects is where we specify the user details. The roleRef section is where we provide the details of the role we created.

Now create the role binding using the kubectl create command.

$ kubectl create -f devuser-developer-binding.yaml

Note that the roles and role bindings fall under the scope of namespace. So here the dev-user gets access to PODs and ConfigMaps within the default namespace.

If you want to limit the dev user’s access within a different namespace then specify the namespace within the metadata of the definition file while creating them.

View RBAC

Now to view the created roles run the kubectl get roles command. To list role bindings run the kubectl get rolebindings command.

$ kubectl get roles
NAME         AGE
developer    15s

$ kubectl get rolebindings 
NAME                             AGE
devuser-developer-binding        5s

To view more details about the role, run the following command

$ kubectl describe role developer

Here you see the details about the resources and permissions for each resource. Similarly to view details about role bindings run the following command.

$ kubectl describe rolebinding devuser-developer-binding
Check access

What if you being a user would like to see if you have access to a particular resource in the cluster? You can use the following command and check if you can, say create deployments or say delete nodes.

$ kubectl auth can-i create deployments
yes

$ kubectl auth can-i delete nodes
no

If you are an administrator then you can even impersonate another user to check their permission.

For instance say you are tasked to create necessary set of permissions for a user to perform a set of operations and you did that but you would like to test if what you did is working. You don’t have to authenticate as the user to test it.

Instead you can use the same command with the as user option like below.

$ kubectl auth can-i create deployments --as dev-user
no

$ kubectl auth can-i create pods --as dev-user
yes

Since we did not grant the developer permissions to create deployments it returns no. The dev user has access to creating pods though.

You can also specify the namespace in the command like below

$ kubectl auth can-i create pods --as dev-user --name-space waytoeasylearn
no

The dev-user does not have permission to create a pod in the waytoeasylearn namespace it returns no.

Well a quick note on resource names we just saw how you can provide access to users for resources like PODs within the namespace? You can go one level down and allow access to specific resources alone.

For example say you have 5 PODs (blue, green, yellow, orange and red) in namespace. You want to give access to a user to pods, but not all PODs. You can restrict access to the green and orange POD alone by adding a resourceNames field to the rule.

apiVersion: rbac.authorization.k8s.io/v1 
kind: Role 
metadata:
   namespace: default
   name: developer
rules:
- apiGroups: [""] # "" indicates the core API group  
  resources: ["pods"]
  verbs: ["get", "create", "update"]
  resourceNames: ["green","orange"]
Role Based Access Controls
Scroll to top