In this lecture, we look at role-based access controls in much more detail.
So how do we create a role.
We do that 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 need 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 lectures 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 and delete. To allow the developers to create
configmaps,
we add another rule to create ConfigMap.
We can add multiple rules for a single role like this.
Create the role using the kubectl create role command.
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.
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. Creat the role binding using the kubectl create command.
Also 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 to view the created roles.
run the kubectl get roles command. To list role bindings run the kubectl get rolebindings command.
To view more details about the role, run the kubectl describe role developer command.
Here you see the details about the resources and permissions for each resource similarly to view details
about role bindings run the kubectl
describe rolebindings command.
Here you can see details about an existing role binding.
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 kubetl auth can-I command and check if you can, say create deployments. Or say delete
nodes. If you are an administrator then you can even impersonate another use 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 this 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 this.
The dev-user does not have permission to create a pod in the test namespace.
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 five pods in namespace.
You want to give access to a user to pods, but not all pods.
You can restrict access to the blue and orange pod alone by adding a resourceNames field to the rule.
well that's it for this lecture.
Head over to the practice exercises section and practice working with role based access controls.