WEBVTT 00:00.747 --> 00:04.593 Okay. In this lab, we're going to look at role-based access controls. 00:05.183 --> 00:08.563 The first question is inspect the environment and identify 00:09.023 --> 00:11.446 authorization modes configured on the cluster. 00:13.415 --> 00:17.201 Let's look at the kube-apiserver, so 00:18.402 --> 00:21.449 /etc/kubernetes/manifests/ 00:22.899 --> 00:25.532 kube-apiserver.yaml. 00:26.178 --> 00:29.791 Then here we see the options passed to the kube-apiserver. 00:30.119 --> 00:33.979 If you look at the authorization mode, you have node and RBAC. 00:34.653 --> 00:37.993 That's one way of checking that. The other way is to 00:41.246 --> 00:42.893 run docker ps. 00:45.061 --> 00:46.067 No, sorry. 00:47.007 --> 00:50.127 We're going to look at the processes on the control plane, so we're going to do ps 00:51.403 --> 00:57.169 -aux grep or authorization mode. 00:58.608 --> 00:59.879 We know that ultimately, 01:00.661 --> 01:04.940 all containers are running as processes on on the control plane. 01:08.183 --> 01:12.359 We look at the authorization mode configured on the kube-apiserver. 01:12.440 --> 01:14.693 This is basically the kube-apiserver service. 01:15.854 --> 01:19.107 If you look at the authorization mode, it's set to node and RBAC. 01:19.392 --> 01:24.659 These are two ways of finding out the settings passed to the kube-apiserver, 01:25.322 --> 01:26.816 so it's node and RBAC. 01:30.439 --> 01:33.278 How many roles exist in the default namespace? 01:33.399 --> 01:39.305 We're going to do kubectl get roles, 01:40.195 --> 01:46.731 and in the default namespace, there are no roles, so let's select that. 01:46.913 --> 01:49.267 How many roles exist in all namespaces? 01:49.991 --> 01:53.237 You're going to pass into -A to get all namespaces. 01:53.918 --> 01:57.278 Instead of counting, we're going to do no headers. 01:58.968 --> 02:04.141 That prints it without this header, and then we'll do a word count 02:06.191 --> 02:09.524 to count all the lines and we get- 02:11.701 --> 02:15.048 and the answer to that is 12. Let's select 12. 02:18.157 --> 02:21.224 Okay. Now what are the resources the kube-proxy role 02:21.305 --> 02:23.705 in the kube-system namespace is given access to? 02:24.302 --> 02:26.715 Here we have the kube-proxy role, 02:27.659 --> 02:29.696 so let's check that out. 02:29.777 --> 02:31.690 Let's do a kubectl describe 02:32.647 --> 02:36.904 role kube-proxy 02:38.111 --> 02:44.236 -n kube-system. 02:45.809 --> 02:49.979 We see that the resources that this kube-proxy role 02:50.179 --> 02:54.826 has access to is the configmap, so configmaps. 02:58.051 --> 03:01.164 What actions can the kube-proxy role perform on the configmap? 03:02.274 --> 03:05.808 The actions that you can perform for now is just get. 03:10.759 --> 03:12.662 I accidentally clicked that. 03:13.220 --> 03:14.954 Which of the following statements are true? 03:16.373 --> 03:20.963 Kube-proxy role can get details of the configmap object 03:21.269 --> 03:23.035 by the name kube-proxy. 03:23.903 --> 03:29.122 We know that that's true, because kube-proxy role can get 03:29.766 --> 03:32.918 the configmap by the name kube-proxy. 03:33.438 --> 03:35.552 Kube-proxy role can delete the configmap. 03:36.295 --> 03:42.334 It cannot delete the config map, because it doesn't have the delete row up here. 03:44.975 --> 03:49.447 The kube-proxy role can only view and update the configmap object by the name. 03:49.754 --> 03:52.841 Obviously, this is incorrect, but still-- 03:55.311 --> 03:59.301 What we need to understand here is that the kube-proxy role can only get 04:00.738 --> 04:03.905 a configmap with the resource name kube-proxy. 04:05.226 --> 04:06.526 That's the correct answer. 04:08.561 --> 04:12.228 Now, which account is the kube-proxy role assigned to? 04:14.753 --> 04:16.856 For that, we need to look at role binding. 04:16.937 --> 04:23.338 Let's look at role bindings 04:24.032 --> 04:26.360 in the kube-system namespace, 04:29.121 --> 04:31.588 and if you look at this, we see that 04:34.188 --> 04:37.149 the kube-proxy role is part of the kube-proxy rolebinding. 04:38.276 --> 04:40.496 Let's look at the kube-proxy rolebinding. 04:40.775 --> 04:44.675 Now with no details, so you have your kubectl describe 04:45.503 --> 04:47.949 rolebindings 04:51.036 --> 04:58.010 kube-proxy in the kube-system namespace. 04:59.385 --> 05:02.512 Here you can see the group 05:02.746 --> 05:09.100 that it has access to for the account that the kube-proxy role is assigned to. 05:10.360 --> 05:14.563 That's system bootstrappers kubeadm default-node-token. 05:15.153 --> 05:19.246 That's the group that it's assigned to. 05:21.417 --> 05:23.289 A dev user is created. 05:24.238 --> 05:26.752 The user' details have been added to the kubeconfig file. 05:27.610 --> 05:32.417 Let's look at the kubeconfig file. Let's do a kubectl config view. 05:33.607 --> 05:35.820 Now we can see that there's a user named dev-user. 05:40.345 --> 05:42.378 Inspect the permissions granted to the user. 05:42.613 --> 05:45.526 Check if the user can list parts in the default namespace. 05:45.850 --> 05:49.070 We can do kubectl get pods, 05:49.869 --> 05:53.086 and we can use the as dev user 05:54.614 --> 05:58.262 option to view as the dev user. 05:59.987 --> 06:01.555 As you can see, it's forbidden. 06:01.727 --> 06:04.812 The user, dev-user cannot list resource pods 06:04.893 --> 06:07.286 in the API group in the default namespace. 06:07.806 --> 06:10.807 The dev user has permissions, does not have permissions. 06:10.888 --> 06:12.047 That's the correct answer. 06:14.031 --> 06:16.432 Now, create the necessary roles and role bindings 06:16.964 --> 06:21.168 required for the dev user to create, list, and delete parts in the default namespace. 06:24.668 --> 06:29.134 First, we have to create the role and role bindings for the dev-user. 06:30.728 --> 06:34.862 We're going to do a kubectl create role. Let's take a look at the help. 06:35.873 --> 06:40.871 We have created role, then the role name, and then the verbs. 06:42.548 --> 06:46.989 The verbs could be passed in comma separated and the resources 06:47.436 --> 06:50.369 that the role has access to. 06:54.505 --> 06:58.318 Let's do that. It's kubectl create a role. 07:00.103 --> 07:05.111 Verbs are going to be list, create, and delete 07:05.864 --> 07:10.805 and resources are going to be pods. 07:11.778 --> 07:13.398 Let's also give it a name. 07:14.442 --> 07:19.500 The name is developer. It's resource, I think. 07:21.664 --> 07:23.830 Let's describe the role. 07:28.146 --> 07:32.480 You can see that the developer role is created with list, create, and delete 07:33.710 --> 07:34.923 access to parts. 07:35.773 --> 07:38.867 Now we have to create a role binding and bind it to the-- 07:41.022 --> 07:47.526 Let's do a kubectl create role binding help. 07:48.783 --> 07:52.063 We can create a role binding. 07:52.586 --> 07:54.639 The name is going to be dev user binding, 07:55.160 --> 07:57.008 then the cluster role or 07:59.710 --> 08:02.244 user or end group. 08:02.464 --> 08:05.370 What we want to do is we want to bind the dev user. 08:05.451 --> 08:10.403 [silence] 08:11.690 --> 08:13.800 The role name we're going to use role. 08:14.296 --> 08:19.036 We're going to use kubectl create role binding 08:19.690 --> 08:22.797 and dev user binding, 08:23.549 --> 08:27.048 the role is going to be developer, 08:27.925 --> 08:34.384 and the user is going to be dev-user. 08:36.456 --> 08:41.023 Okay, let's check role binding, 08:44.898 --> 08:47.245 dev-user binding. 08:47.946 --> 08:50.693 We can see user, dev-user 08:51.759 --> 08:54.545 is now associated to develop the role. 08:56.353 --> 09:03.019 Okay. Now, the dev user is trying to get details about the dark blue app 09:03.383 --> 09:04.840 pod in the blue namespace, 09:05.368 --> 09:08.122 but there is an issue so investigate and fix the issue. 09:09.169 --> 09:15.443 Let's do that. As dev user, 09:16.461 --> 09:19.708 I'm going to get details about 09:19.856 --> 09:23.622 the pod dark blue app, 09:24.530 --> 09:31.081 but in the blue namespace or in the blue namespace. 09:31.654 --> 09:35.719 It says, "Dark blue app is forbidden. 09:35.800 --> 09:38.306 User, dev-user cannot get resource pods 09:38.387 --> 09:41.761 in the API group in the namespace globe," 09:43.510 --> 09:45.870 but it says that we've created the required roles and role binding. 09:45.951 --> 09:47.107 Let's take a look at that. 09:47.188 --> 09:50.742 Let's take the look at the roles in the blue namespace. 09:51.151 --> 09:53.698 We can see that there's a developer role, and then there's 09:54.482 --> 09:57.209 also role bindings in the blue namespace. 09:57.613 --> 10:02.847 There's the dev user binding. Let's take a closer look at those. 10:04.780 --> 10:11.777 Describe role developer 10:13.040 --> 10:14.413 in the blue namespace, 10:16.237 --> 10:21.537 and we see that it has resource pods 10:22.078 --> 10:24.751 and the resource names blue app 10:24.997 --> 10:27.203 that can do a get watch, create, and delete, 10:27.587 --> 10:30.880 but here, as you can see, it's not blue, it's dark blue app. 10:31.133 --> 10:33.493 That's basically the reason that you can't access that. 10:33.878 --> 10:38.675 We're going to edit the role developer in the blue namespace. 10:40.350 --> 10:42.447 What we're going to do is 10:45.093 --> 10:47.827 change this to dark blue app. 10:53.237 --> 10:55.066 Now let's do that again. 10:55.227 --> 10:58.644 We're going to do a get pod dark blue app 10:58.961 --> 11:01.455 in the blue namespace as the user dev user. 11:02.733 --> 11:06.128 We can see that it is now in the running state. That's fixed. 11:10.060 --> 11:13.853 Now, we would like to grant the dev user permissions to create 11:13.954 --> 11:15.658 deployments in the blue namespace. 11:16.038 --> 11:18.985 Let's try that as the dev user, 11:19.468 --> 11:23.508 I want to create a deployment, called engine X, 11:23.976 --> 11:27.956 say with the image engine X, this could be anything. 11:28.050 --> 11:32.029 This is just a test, but in the blue namespace. 11:32.536 --> 11:34.037 When I try to do that it says, 11:34.370 --> 11:37.292 "The user dev user cannot create resource deployments 11:37.485 --> 11:40.272 in API group apps in the default, 11:40.722 --> 11:42.115 in the blue namespace." 11:43.890 --> 11:49.350 What we have to do is we're going to edit the role of developer, 11:49.728 --> 11:52.728 which is used by the dev user in the blue namespace. 11:54.113 --> 11:57.794 What we're going to do is, so this is one rule that allows 11:58.445 --> 12:02.412 a get watch and creates and delete on the dark blue app pod. 12:03.025 --> 12:06.571 What we're going to do is we're going to create a new rule, 12:08.112 --> 12:11.909 so we can just copy this and we're going to paste that. 12:12.530 --> 12:17.784 What we'll do is instead, the API groups for 12:19.291 --> 12:21.795 deployment is apps. We're going to put apps. 12:22.679 --> 12:24.076 We're not going to give any resource names, 12:24.157 --> 12:29.058 because we want to be able to create any resource name here, 12:29.200 --> 12:34.438 we're going to say deployment, and we're going to allow get, watch, create. 12:34.930 --> 12:40.477 After creating, we obviously want to get or watch it or eventually. 12:40.616 --> 12:42.436 Let's just give that. 12:45.282 --> 12:48.549 That's done, let's verify that 12:49.932 --> 12:55.783 role developer in the blue namespace, and we see that we have deployment apps. 12:56.414 --> 12:59.087 We're now able to get, watch, create and delete. 12:59.509 --> 13:03.249 Let's try the command again to create a deployment called engine X 13:03.677 --> 13:05.503 in the Google namespace. 13:07.796 --> 13:11.440 That's still not working. Let's see where that is. 13:13.513 --> 13:16.333 Actually, it should be deployments. Sorry about that. 13:17.407 --> 13:18.807 Let's go and change that. 13:24.485 --> 13:27.573 Let's try that again. That works. 13:29.838 --> 13:35.833 That should be the fix to this. All right. That's the end of this lab.