WEBVTT 00:00.910 --> 00:06.470 In this lecture, we look at role-based access controls in much more detail. 00:06.670 --> 00:09.020 So how do we create a role. 00:09.160 --> 00:11.590 We do that by creating a role object. 00:11.860 --> 00:18.920 So we create a role definition file with the API version set to rbac.authorization.K8s. 00:18.950 --> 00:22.970 io/v1 and kind said to role. 00:23.260 --> 00:30.160 We need the role developer as we are creating this role for developers and then we specify rules. 00:30.160 --> 00:37.510 Each rule has three sections- apiGroups, resources, and verbs. The same things that we talked about in 00:37.570 --> 00:40.780 one of the previous lectures for core group. 00:40.780 --> 00:47.860 You can leave the API group's section as blank for any other group you specify the group name the resources 00:47.860 --> 00:51.600 that we want to give developers access to our pods. 00:51.640 --> 00:59.080 The actions that they can take are list, get, create and delete. To allow the developers to create 00:59.080 --> 00:59.980 configmaps, 00:59.980 --> 01:02.620 we add another rule to create ConfigMap. 01:02.770 --> 01:06.420 We can add multiple rules for a single role like this. 01:07.560 --> 01:13.600 Create the role using the kubectl create role command. 01:13.780 --> 01:17.640 The next step is to link the user to that role. 01:17.680 --> 01:24.380 For this we create another object called RoleBinding. The role binding object links 01:24.400 --> 01:26.950 A user object to a role. 01:27.280 --> 01:31.490 We will name it devuser-developer-binding. 01:31.690 --> 01:33.680 The kind is RoleBinding. 01:33.820 --> 01:35.380 It has two sections. 01:35.380 --> 01:41.920 The subjects is where we specify the user details. The roleRef section is where we provide the details 01:41.980 --> 01:48.210 of the role we created. Creat the role binding using the kubectl create command. 01:48.220 --> 01:54.410 Also note that the roles and role bindings fall under the scope of namespace. 01:54.490 --> 02:00.840 So here the dev-user gets access to pods and configmaps within the default namespace. 02:01.060 --> 02:07.180 If you want to limit the dev user's access within a different namespace then specify the namespace within 02:07.180 --> 02:13.030 the metadata of the definition file while creating them to view the created roles. 02:13.030 --> 02:20.530 run the kubectl get roles command. To list role bindings run the kubectl get rolebindings command. 02:20.830 --> 02:26.380 To view more details about the role, run the kubectl describe role developer command. 02:26.380 --> 02:32.990 Here you see the details about the resources and permissions for each resource similarly to view details 02:32.990 --> 02:35.730 about role bindings run the kubectl 02:35.750 --> 02:37.840 describe rolebindings command. 02:37.880 --> 02:43.260 Here you can see details about an existing role binding. 02:43.350 --> 02:50.900 What if you being a user would like to see if you have access to a particular resource in the cluster. 02:51.010 --> 02:59.540 ? You can use the kubetl auth can-I command and check if you can, say create deployments. Or say delete 02:59.540 --> 03:07.020 nodes. If you are an administrator then you can even impersonate another use to check their permission. 03:07.040 --> 03:12.740 For instance say you are tasked to create necessary set of permissions for a user to perform a set of 03:12.800 --> 03:18.500 operations and you did that but you would like to test if what you did is working. 03:18.560 --> 03:21.230 You don't have to authenticate as the user to test it. 03:21.230 --> 03:29.940 Instead you can use the same command with the as user option like this since we did not grant the developer 03:29.940 --> 03:32.400 permissions to create deployments it returns 03:32.400 --> 03:40.580 no. The dev user has access to creating pods though. You can also specify the namespace in the command 03:40.580 --> 03:40.780 like this. 03:40.800 --> 03:47.660 The dev-user does not have permission to create a pod in the test namespace. 03:47.660 --> 03:56.210 Well a quick note on resource names we just saw how you can provide access to users for resources like 03:56.210 --> 03:58.660 pods within the namespace. 03:58.730 --> 04:03.500 You can go one level down and allow access to specific resources alone. 04:03.500 --> 04:07.160 For example say you have five pods in namespace. 04:07.370 --> 04:12.110 You want to give access to a user to pods, but not all pods. 04:12.230 --> 04:18.440 You can restrict access to the blue and orange pod alone by adding a resourceNames field to the rule. 04:19.900 --> 04:21.820 well that's it for this lecture. 04:23.040 --> 04:27.550 Head over to the practice exercises section and practice working with role based access controls.