WEBVTT 00:00.630 --> 00:07.580 Before we head into authorization it is necessary to understand about API groups in kubernetes. 00:07.650 --> 00:10.890 But first, what is the Kubernetes API? 00:10.980 --> 00:16.750 We learned about the Kube API server. Whatever operations we have done so far with the cluster, 00:17.230 --> 00:24.000 we have been interacting with the API server one way or the other. Either through the kubectl utility 00:24.480 --> 00:32.040 or directly. Say we want to check the version, we can access the api server at the master nodes 00:32.130 --> 00:38.670 address followed by the port which is 6443 by default and the API version. 00:38.670 --> 00:45.900 It returns the version. Similarly to get the list of pods, you would access the url api/v1/pods. 00:45.990 --> 00:46.860 It returns the version. Similarly to get the list of pods, you would access the url api/v1/pods. 00:50.500 --> 01:00.490 Our focus in this lecture is about these API paths. The /version and /api. The Kubernetes API is grouped 01:00.640 --> 01:08.990 into multiple such groups based on their purpose. Such as one for apis, one for healthz, metrics 01:08.990 --> 01:16.490 and logs etc. The version API is for viewing the version of the cluster as we just saw The Matrix and 01:16.490 --> 01:22.710 healthz api are used to monitor the health of the cluster. The logs for integrating with third 01:22.710 --> 01:24.540 party logging applications. 01:24.540 --> 01:30.390 In this video we will focus on the API is responsible for the cluster of functionality 01:33.780 --> 01:42.560 These APIs are categorized into two. The core group and the named group. The core group is where all core 01:42.560 --> 01:52.870 functionality exists. Such as namespaces, pods, replication controllers, events, endpoints, nodes, bindings, 01:52.900 --> 02:02.750 Persistent volumes, persistent volume claims, configmaps, secrets, services etc. The named group API is 02:03.080 --> 02:09.380 are more organized and going forward all the newer features are going to be made available to these 02:09.440 --> 02:11.270 named groups. 02:11.490 --> 02:20.540 It has groups under it for apps, extensions, networking, storage, authentication, authorization certificates etc. Shown 02:20.540 --> 02:29.240 here are just a few. Within apps, you have deployments, replicasets, statefulsets. within networking 02:29.240 --> 02:35.240 you have network policies certificates have these certificates sign requests that we talked about earlier 02:35.240 --> 02:43.050 in the section so the ones at the top are API groups and the ones at the bottom are resources in those 02:43.050 --> 02:44.250 groups. 02:44.250 --> 02:49.200 Each resource in this has a set of actions associated with them. 02:49.200 --> 02:55.500 Things that you can do with these resources such as list the deployments get information about one of 02:55.500 --> 03:02.670 these deployments create a deployment delete a deployment update a deployment watch a deployment etc. 03:03.060 --> 03:11.700 These are known as verbs. The Kubernetes API reference page can tell you what the API group is for each 03:11.790 --> 03:19.600 object select an object and the first section in the documentation page shows its group details . 03:19.600 --> 03:23.160 v1/core is just v1. 03:23.200 --> 03:29.920 You can also view these on your Kubernetes cluster. Access your kube-api server at port 6443, without 03:29.920 --> 03:36.430 any path and it will list you the available api groups. And then within the named api groups it returns 03:36.490 --> 03:44.230 all supported groups. A quick note on accessing the cluster API like that. 03:44.580 --> 03:48.470 If you were to access the API directly through curl as shown here, 03:48.470 --> 03:54.900 then you will not be allowed access except for certain APIs like version, as you have not specified 03:55.020 --> 04:01.570 any authentication mechanisms. So you have to authenticate to the API using your certificate files by passing 04:01.680 --> 04:09.550 them in the command line like this. An alternate option is to start a kubectl proxy client.The 04:09.550 --> 04:16.900 kubectl proxy command, launches a proxy service locally on port 8001 and uses credentials and 04:16.900 --> 04:21.250 certificates from your kubeconfig file to access the cluster. 04:21.250 --> 04:25.700 That way you don’t have to specify those in the curl command. 04:25.720 --> 04:32.710 Now you can access the kubectl proxy service at port 8001 and the proxy will use the credentials 04:32.710 --> 04:37.800 from kube-config file to forward your request to the kube api server. 04:37.840 --> 04:46.250 This will list all available APIs at root. so hear are 2 terms that kind of sound the same. 04:46.250 --> 04:51.770 The Kube proxy and kubectl proxy well they are not the same. 04:51.770 --> 04:54.670 We discussed about kube-proxy earlier in this course. 04:54.750 --> 05:00.380 It is used to enable connectivity between parts and services across different nodes in the cluster. 05:00.380 --> 05:05.040 We discuss about kube-proxy in much more detail later in this course. 05:05.240 --> 05:12.350 Whereas kubectl proxy is an HTTP proxy service created by kubectl utility to access the 05:12.350 --> 05:14.520 kube-api server. 05:14.620 --> 05:16.810 So what to take away from this. 05:17.170 --> 05:23.170 All resources in Kubernetes are grouped into different api groups. At the top level 05:23.320 --> 05:28.380 you have core api group and named api group. Under the named api group 05:28.390 --> 05:32.170 You have one for each section under this API group. 05:32.170 --> 05:39.910 You have the different resources and each resource has a set of associated actions known as verbs in 05:39.910 --> 05:42.410 the next section on authorization. 05:42.460 --> 05:47.770 We can see how we use these to allow or deny access to users. 05:47.810 --> 05:51.400 Well that’s it for this lecture. I will see you in the next.