1 00:00:00,790 --> 00:00:04,960 We discussed about roles and role bindings in the previous lecture. 2 00:00:05,140 --> 00:00:12,040 In this lecture we will talk about cluster roles and cluster roles bindings when we talked about roles 3 00:00:12,040 --> 00:00:12,970 and role bindings. 4 00:00:12,970 --> 00:00:20,930 We said that roles and role bindings are namespaced meaning they are created within namespaces. 5 00:00:20,980 --> 00:00:27,520 If you don't specify in namespace they're created in the default namespace and control access within 6 00:00:27,520 --> 00:00:34,740 that namespace alone in one of the previous lectures we discussed about name spaces and how it helps 7 00:00:34,740 --> 00:00:41,690 in grouping or isolating resources like pods, deployments and services. But what about other resources 8 00:00:41,710 --> 00:00:42,130 like 9 00:00:42,350 --> 00:00:47,090 nodes? Can you group or isolate nodes within a namespace? 10 00:00:47,240 --> 00:00:51,980 Like can you say node 01 is part of the dev namespace. 11 00:00:51,980 --> 00:00:56,800 No, those are cluster wide or cluster scoped resources. 12 00:00:56,930 --> 00:01:00,590 They cannot be associated to any particular namespace. 13 00:01:00,950 --> 00:01:08,460 So the resources are categorized as either namespaced or cluster scoped. 14 00:01:08,470 --> 00:01:13,780 Now we have seen a lot of namespaced resources throughout this course. Like pods, replicasets, and 15 00:01:13,780 --> 00:01:21,430 jobs, deployments, services, secrets, and in the last lecture we saw 2 new. Roles and Rolebindings. 16 00:01:21,430 --> 00:01:26,410 These resources are created in the namespace you specify when you create them. 17 00:01:26,410 --> 00:01:32,050 If you don't specify a namespace they are created in the default namespace to view them or delete them 18 00:01:32,080 --> 00:01:32,910 or update them. 19 00:01:32,920 --> 00:01:39,640 you always specify the right namespace. The cluster scoped resources are those where you don’t specify 20 00:01:39,640 --> 00:01:40,440 a namespace. 21 00:01:40,510 --> 00:01:46,780 when you create them. Like nodes, persistent volumes, persistent clusterroles and clusterrolebinding 22 00:01:47,200 --> 00:01:48,100 that we're going to look at. 23 00:01:48,100 --> 00:01:54,790 In this lecture certificate signing requests we saw earlier and namespace objects themselves are of 24 00:01:54,790 --> 00:01:57,880 course not namespaced. 25 00:01:57,910 --> 00:02:05,080 Note that this is not a comprehensive list of resources to see a full list of namespace and non namespace 26 00:02:05,080 --> 00:02:13,750 resources run the kubectl api-resources command with the namespaced option set. In the previous lecture 27 00:02:13,840 --> 00:02:20,680 we saw how to authorize a user to namespace resources We used Roles and Rolebindings for that. But how 28 00:02:20,680 --> 00:02:28,990 do we authorize users to cluster wide resources like nodes or persistent volumes that is where you use 29 00:02:29,140 --> 00:02:36,290 cluster roles and cluster role bindings cluster roles are just like roles except they are for a cluster 30 00:02:36,290 --> 00:02:43,080 scoped resources for example a cluster admin role can be created to provide a cluster administrator 31 00:02:43,140 --> 00:02:46,720 permissions to view create or delete nodes in a cluster. 32 00:02:47,400 --> 00:02:54,210 Similarly if storage administrator role can be created to authorize a storage admin to create persistent 33 00:02:54,210 --> 00:03:01,940 volumes and claims create a cluster all definition file with the kind cluster roll and specify the rules 34 00:03:01,970 --> 00:03:03,990 as we did before this case. 35 00:03:04,130 --> 00:03:09,520 The resources are nodes then create the cluster role. 36 00:03:09,660 --> 00:03:13,480 The next step is to link the user to that cluster role. 37 00:03:13,530 --> 00:03:20,870 For this we create another object called cluster role binding the role binding object links the user 38 00:03:21,050 --> 00:03:22,210 to the role. 39 00:03:22,280 --> 00:03:29,510 We will name it cluster-admin-role-binding. The kind is ClusterRoleBinding. Under subjects we specify 40 00:03:29,510 --> 00:03:35,690 the user details cluster admin user in this case the role ref section is where we provide the details 41 00:03:35,780 --> 00:03:42,890 of the cluster role we created create the role binding using the kubectl create command one thing 42 00:03:42,890 --> 00:03:49,220 to note before I let you go we said that cluster roles and bindings are used for clusters of resources 43 00:03:49,670 --> 00:03:56,230 but that is not a hard rule you can create a cluster role for namespace resources as well. 44 00:03:56,510 --> 00:04:03,540 When you do that the user will have access to these resources across all name spaces. 45 00:04:03,650 --> 00:04:09,260 Earlier when we created a role to authorize a user to access pods the user had access to the pods in 46 00:04:09,260 --> 00:04:12,780 a particular namespace along with cluster rules. 47 00:04:12,800 --> 00:04:20,850 When you authorize a user to access the pods the user gets access to all pods across the cluster. Kubernetes 48 00:04:20,880 --> 00:04:23,960 creates a number of cluster roles by default. 49 00:04:24,170 --> 00:04:30,550 when the cluster is first setup. We will explore those in the practice tests coming up. 50 00:04:30,650 --> 00:04:31,150 Good luck.