1

00:00:00,910 --> 00:00:06,470

In this lecture, we look at role-based access controls in much more detail.



2

00:00:06,670 --> 00:00:09,020

So how do we create a role.



3

00:00:09,160 --> 00:00:11,590

We do that by creating a role object.



4

00:00:11,860 --> 00:00:18,920

So we create a role definition file with the API version set to rbac.authorization.K8s.



5

00:00:18,950 --> 00:00:22,970

io/v1 and kind said to role.



6

00:00:23,260 --> 00:00:30,160

We need the role developer as we are creating this role for developers and then we specify rules.



7

00:00:30,160 --> 00:00:37,510

Each rule has three sections- apiGroups, resources, and verbs.  The same things that we talked about in



8

00:00:37,570 --> 00:00:40,780

one of the previous lectures for core group.



9

00:00:40,780 --> 00:00:47,860

You can leave the API group's section as blank for any other group you specify the group name the resources



10

00:00:47,860 --> 00:00:51,600

that we want to give developers access to our pods.



11

00:00:51,640 --> 00:00:59,080

The actions that they can take are list, get, create and delete. To allow the developers to create



12

00:00:59,080 --> 00:00:59,980

configmaps,



13

00:00:59,980 --> 00:01:02,620

we add another rule to create ConfigMap.



14

00:01:02,770 --> 00:01:06,420

We can add multiple rules for a single role like this.



15

00:01:07,560 --> 00:01:13,600

Create the role using the kubectl create role command.



16

00:01:13,780 --> 00:01:17,640

The next step is to link the user to that role.



17

00:01:17,680 --> 00:01:24,380

For this we create another object called RoleBinding.  The role binding object links



18

00:01:24,400 --> 00:01:26,950

A user object to a role.



19

00:01:27,280 --> 00:01:31,490

We will name it devuser-developer-binding.



20

00:01:31,690 --> 00:01:33,680

The kind is RoleBinding.



21

00:01:33,820 --> 00:01:35,380

It has two sections.



22

00:01:35,380 --> 00:01:41,920

The subjects is where we specify the user details. The roleRef section is where we provide the details



23

00:01:41,980 --> 00:01:48,210

of the role we created. Creat the role binding using the kubectl create command.





24

00:01:48,220 --> 00:01:54,410

Also note that the roles and role bindings fall under the scope of namespace.



25

00:01:54,490 --> 00:02:00,840

So here the dev-user gets access to pods and configmaps within the default namespace.



26

00:02:01,060 --> 00:02:07,180

If you want to limit the dev user's access within a different namespace then specify the namespace within



27

00:02:07,180 --> 00:02:13,030

the metadata of the definition file while creating them to view the created roles.



28

00:02:13,030 --> 00:02:20,530

run the kubectl get roles command. To list role bindings run the kubectl get rolebindings command.



29

00:02:20,830 --> 00:02:26,380

To view more details about the role, run the kubectl describe role developer command.



30

00:02:26,380 --> 00:02:32,990

Here you see the details about the resources and permissions for each resource similarly to view details



31

00:02:32,990 --> 00:02:35,730

about role bindings run the kubectl



32

00:02:35,750 --> 00:02:37,840

describe rolebindings command.



33

00:02:37,880 --> 00:02:43,260

Here you can see details about an existing role binding.



34

00:02:43,350 --> 00:02:50,900

What if you being a user would like to see if you have access to a particular resource in the cluster.



35

00:02:51,010 --> 00:02:59,540

? You can use the kubetl auth can-I command and check if you can, say create deployments.  Or say delete



36

00:02:59,540 --> 00:03:07,020

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



37

00:03:07,040 --> 00:03:12,740

For instance say you are tasked to create necessary set of permissions for a user to perform a set of



38

00:03:12,800 --> 00:03:18,500

operations and you did that but you would like to test if what you did is working.



39

00:03:18,560 --> 00:03:21,230

You don't have to authenticate as the user to test it.



40

00:03:21,230 --> 00:03:29,940

Instead you can use the same command with the as user option like this since we did not grant the developer



41

00:03:29,940 --> 00:03:32,400

permissions to create deployments it returns



42

00:03:32,400 --> 00:03:40,580

no. The dev user has access to creating pods though. You can also specify the namespace in the command



43

00:03:40,580 --> 00:03:40,780

like this.



44

00:03:40,800 --> 00:03:47,660

The dev-user does not have permission to create a pod in the test namespace.



45

00:03:47,660 --> 00:03:56,210

Well a quick note on resource names we just saw how you can provide access to users for resources like



46

00:03:56,210 --> 00:03:58,660

pods within the namespace.



47

00:03:58,730 --> 00:04:03,500

You can go one level down and allow access to specific resources alone.



48

00:04:03,500 --> 00:04:07,160

For example say you have five pods in namespace.



49

00:04:07,370 --> 00:04:12,110

You want to give access to a user to pods, but not all pods.



50

00:04:12,230 --> 00:04:18,440

You can restrict access to the blue and orange pod alone by adding a resourceNames field to the rule.



51

00:04:19,900 --> 00:04:21,820

well that's it for this lecture.



52

00:04:23,040 --> 00:04:27,550

Head over to the practice exercises section and practice working with role based access controls.