WEBVTT 00:01.900 --> 00:08.420 In this lecture we'll look at how to generate the certificates for the cluster to generate certificates. 00:08.420 --> 00:17.010 there are different tools available such as easyrsa, openssl or cfssl etc or many others. 00:17.150 --> 00:21.940 In this lecture we will use Open SSL tools to generate the certificates. 00:21.950 --> 00:23.270 This is where we left off. 00:23.300 --> 00:25.930 We will start with the CA certificates. 00:25.940 --> 00:33.510 First we create a private key using the openssl command, openssl genrsa –out ca.key. 00:33.530 --> 00:34.370 First we create a private key using the openssl command, openssl genrsa –out ca.key. 00:34.370 --> 00:38.110 Then we use the Open SSL requests command along with the key. 00:38.110 --> 00:44.330 We just created to generate a certificate signing request the certificate signing request is like a 00:44.330 --> 00:50.260 certificate with all of your details but with no signature in the certificate signing request with specified 00:50.320 --> 00:51.650 the name of the component. 00:51.650 --> 00:55.790 this certificate is for in the common name or CN field. 00:55.820 --> 01:00.090 In this case, since we are creating a certificate for the kubernetes CA, we name it 01:00.110 --> 01:08.180 Kubernetes-CA. Finally, we sign the certificate using the openssl x509 command and by specifying 01:08.180 --> 01:12.000 the certificate signing request we generated in the previous command. 01:12.110 --> 01:18.470 Since this is for the CA itself, it is self-signed by the CA using its own private key that it generated 01:18.530 --> 01:22.640 in the first step. Going forward for all other certificates 01:22.640 --> 01:25.160 we will use this ca key pair to sign them. 01:25.160 --> 01:29.270 The CA now has its private key and root certificate file. 01:29.290 --> 01:29.680 Great. 01:30.200 --> 01:33.400 Let's now look at generating the client's certificates. 01:33.410 --> 01:35.390 We start with the admin user. 01:35.390 --> 01:40.750 We follow the same process where we create a private key for the admin user using the Open SSL command. 01:40.790 --> 01:46.460 We then generate a CSR and that is where we specify the name of the admin user, which is kube-admin. 01:46.470 --> 01:48.230 A quick note about the name. 01:48.350 --> 01:50.410 it doesn’t really have to be kube-admin. 01:50.510 --> 01:51.740 It could be anything. 01:51.800 --> 01:56.100 but remember this is the name that the kubectl client authenticates with 01:56.180 --> 01:58.290 when you run kubectl commands. 01:58.650 --> 02:02.770 So in the audit logs and elsewhere this is the name that you will see. 02:02.960 --> 02:05.670 So provide a relevant name in this field. 02:05.750 --> 02:11.360 Finally, generate a signed certificate using the openssl x509 command. 02:11.360 --> 02:17.210 But this time, you specify the CA certificate and the CA key. You are signing your certificate with the 02:17.210 --> 02:24.740 CA key pair. That makes this a valid certificate within your cluster. The signed certificate is then output 02:24.770 --> 02:31.460 to admin.crt file. That is the certificate that the admin user will use to authenticate to kubernetes 02:31.470 --> 02:32.150 cluster. 02:32.150 --> 02:38.690 If you look at it, this whole process of generating a key and a certificate pair is similar to creating 02:38.690 --> 02:40.890 a user account for a new user. 02:40.970 --> 02:46.520 The certificate is the validated user I.D. and the key is like the password. 02:46.550 --> 02:50.250 It's just that it's much more secure than a simple user name and password. 02:50.360 --> 02:51.980 So this is for the admin user. 02:52.040 --> 02:55.670 How do you differentiate this user from any other users. 02:55.670 --> 03:02.020 The user account needs to be identified as an admin user and not just another basic user. 03:02.180 --> 03:06.380 You do that by adding the group details for the user in the certificate. 03:06.380 --> 03:13.160 In this case a group named SYSTEM:MASTERS exists on kubernetes with administrative privileges. 03:13.160 --> 03:20.060 We will discuss about groups later. But for now its important to know that you must mention this information 03:20.120 --> 03:22.320 in your certificate signing request. 03:22.370 --> 03:28.220 You can do this by adding group details with the OU parameter while generating a signing 03:28.220 --> 03:28.850 request. 03:28.880 --> 03:35.010 Once it's signed we now have our certificate for the admin user with admin privileges. 03:35.120 --> 03:40.280 We follow the same process to generate client certificates for all other components that access the 03:40.280 --> 03:41.480 kube-api server. 03:41.570 --> 03:46.700 The kube-scheduler. Now the kube-scheduler is a system component part of the kubernetes control plane. 03:47.150 --> 03:51.660 So it’s name must be pre-fixed with the key word “system”. 03:51.660 --> 03:56.810 The same with Kube-controller-manager. It is again a system component. So its name must be prefixed with 03:56.810 --> 03:58.230 the keyword system. 03:58.370 --> 04:05.180 And finally kube-proxy. So far we have created CA certificates, then all of the client certificates including 04:05.180 --> 04:08.480 the admin user, scheduler, controller-manager, kube-proxy. 04:08.690 --> 04:13.460 We will follow the same procedure to create the remaining 3 client certificates for the apiservers 04:13.460 --> 04:14.160 and kubelets 04:14.240 --> 04:18.550 When we create the service certificates for them so we will set them aside for now. 04:18.560 --> 04:21.200 Now what do you do with these certificates. 04:21.200 --> 04:24.290 Take the admin certificate for instance to manage the cluster. 04:24.290 --> 04:29.990 You can use the certificate instead of a user and password in a REST API call you make to the 04:29.990 --> 04:36.160 kube-api server. You specify the key the certificate and the ca certificate as options 04:36.170 --> 04:41.810 That's one simple way the other way is to move all of these parameters into a configuration file called 04:41.810 --> 04:42.960 kube-config. 04:43.100 --> 04:48.340 Within that specify the API server endpoint details the certificates to use etc.. 04:48.440 --> 04:53.720 This is what most of the kubernetes clients use. We will look at kube-config in depth in one of 04:53.720 --> 04:54.770 the upcoming lectures. 04:54.820 --> 05:00.260 Okay so we are now left with the server side certificates but before we proceed. 05:00.320 --> 05:01.320 One more thing. 05:01.430 --> 05:07.140 Remember in the pre-requisite lecture we mentioned that for the clients to validate the certificate sent by 05:07.140 --> 05:09.210 the server and vice versa. 05:09.240 --> 05:14.850 They all need a copy of the certificate authorities public certificate the one that we said is already 05:14.850 --> 05:18.900 installed within the user's browsers in case of a web application. 05:18.900 --> 05:23.310 Similarly, in kubernetes for these various components to verify each other, 05:23.310 --> 05:26.430 they all need a copy of the CA’s root certificate. 05:26.450 --> 05:32.260 So whenever you configure a server or a client with certificates you will need to specify the CA 05:32.270 --> 05:33.620 root certificate as well. 05:33.720 --> 05:36.160 Let's look at the service side certificates now. 05:36.600 --> 05:41.640 Let’s start with the ETCD server. We follow the same procedure as before to generate a certificate for 05:41.640 --> 05:42.160 ETCD. 05:42.480 --> 05:48.240 We will name it ETCD-SERVER. ETCD Server can be deployed as a cluster across multiple servers 05:48.480 --> 05:50.530 as in high availability environment. 05:50.550 --> 05:56.340 In that case to secure communication between the different members in the cluster, we must generate additional 05:56.400 --> 06:02.460 peer certificates.Once the certificates are generated specify them while starting the ETCD server. 06:02.460 --> 06:07.440 There are key and cert file options where you specify the etcdserver keys. 06:07.440 --> 06:10.900 There are other options available for specifying the peer certificates. 06:10.950 --> 06:16.710 And finally as we discussed earlier it requires the CA root certificate to verify the clients 06:16.740 --> 06:18.840 connecting to the ETCD server are valid. 06:18.990 --> 06:20.620 Let’s talk about the kube-api server now. 06:20.630 --> 06:28.320 We generate a certificate for the API server like before. But wait, the API server is the most popular 06:28.320 --> 06:31.180 of all components within the cluster. 06:31.230 --> 06:36.340 Everyone talks to the kube-api server. Every operation goes through the kube-api server. 06:36.420 --> 06:40.440 Anything moves within the cluster the API server knows about it. 06:40.540 --> 06:46.980 You need information you talk to the API server and so it goes by many names and aliases within the 06:46.980 --> 06:48.080 cluster. 06:48.090 --> 06:55.560 It’s real name is kube-api server. But some call it kubernetes. Because for a lot of people who don’t 06:55.560 --> 07:02.700 really know what goes under the hoods of kubernetes, the kube-api server IS kubernetes. Others like 07:02.700 --> 07:05.250 like to call it kubernetes.default. 07:05.640 --> 07:11.910 While some refer to it as kubernete.default.svc. And some like to call it by its full name, 07:12.060 --> 07:17.150 kubernetes.default.svc.cluster.local. 07:17.190 --> 07:25.740 Finally, it is also referred to, in some places, simply by its IP address. The IP address of the host running 07:25.800 --> 07:33.150 the kube-api server. Or the pod running it. So all of these names must be present in the certificate 07:33.300 --> 07:39.930 generated for the kube-api server. Only then those referring to kubernetes by these names will 07:39.930 --> 07:46.870 will be able to establish a valid connection. So we use the same set of commands as earlier to generate a 07:46.870 --> 07:54.230 key. In the certificate signing request you specify the name KUBE-APIserver. But how do you specify 07:54.260 --> 07:56.030 all the alternate names. For that 07:56.030 --> 08:03.470 you must create an openssl config file. Create an openssl.cnf file and specify the alternate names 08:03.470 --> 08:05.900 in the alt name section of the file. 08:05.930 --> 08:10.870 Include all the DNS names the API server goes by as well as the IP address. 08:10.910 --> 08:15.200 Pass this config file as an option while generating the certificate signing request. 08:15.200 --> 08:21.530 Finally, sign the certificate using the CA certificate and key. You then have the kube api server certificate. 08:21.560 --> 08:24.820 It is time to look at where we are going to specify these keys. 08:24.830 --> 08:30.350 Remember to consider the apiserver client certificates that are used by the api server while communicating 08:30.350 --> 08:33.350 as a client to the etcd and kubelet servers. 08:33.350 --> 08:39.320 The location of these certificates are passed in to the kube-api servers executable or service configuration 08:39.320 --> 08:40.090 file. 08:40.310 --> 08:46.370 First the CA file needs to be passed in. Remember every component needs the CA certificate to verify 08:46.370 --> 08:47.180 its clients. 08:47.180 --> 08:52.610 Then we provide the apiserver certificates under the tls-cert options. We then specify the client 08:52.610 --> 08:59.180 certificates used by the kube-api server to connect to the etcd server, again with the CA file. And finally 08:59.470 --> 09:03.050 the kube-api server client certificate to connect to the kubelets. 09:03.050 --> 09:10.130 Next comes the kubelet server. The kubelet server is an HTTPS API server that runs on each node, responsible 09:10.130 --> 09:11.430 for managing the node. 09:11.540 --> 09:17.090 That's where the API server talks to to monitor the node as well as any information regarding what pods 09:17.120 --> 09:18.730 to schedule on this node. 09:18.890 --> 09:23.370 As such, you need a key-certificate pair for each node in the cluster. 09:23.390 --> 09:25.700 Now what do you need these certificates. 09:25.700 --> 09:27.810 Are they all going to be named kubelets? 09:27.960 --> 09:28.950 No. 09:29.360 --> 09:34.680 they will be named after their nodes. Node01, node02 and node03 09:34.700 --> 09:36.540 Once the certificates are created. 09:36.590 --> 09:38.810 use them in the kubelet-config file. 09:38.810 --> 09:43.820 As always you specify the root CA certificate. And then provide the kubelet node certificates. 09:43.820 --> 09:47.000 You must do this for each node in the cluster. 09:47.000 --> 09:52.250 We also talked about a set of client certificates that will be used by the kubelet to communicate with 09:52.250 --> 09:53.750 the kube-api server. 09:53.780 --> 09:57.640 These are used by the kubelet to authenticate into the kube-api server. 09:57.890 --> 09:59.900 They need to be generated as well. 09:59.900 --> 10:01.910 What do you name these certificates. 10:01.910 --> 10:08.320 The API server needs to know which node is authenticated and give it the right set of permissions. 10:08.450 --> 10:12.720 So it requires the nodes to have the right names in the right format. 10:12.740 --> 10:18.110 Since the nodes are system components, like the kube-scheduler, and controller-manger we talked about 10:18.170 --> 10:18.800 earlier. 10:18.800 --> 10:24.700 the format starts with the system keyword. Followed by node and then the node name. 10:24.740 --> 10:27.260 In this case node01 to node03. 10:27.290 --> 10:30.500 And how would the api server give it the right set of permissions? 10:30.500 --> 10:35.740 Remember we specified a group name for the admin user so the admin user gets administrative privileges. 10:35.750 --> 10:40.400 Similarly, the nodes must be added to a group named system:nodes. 10:40.460 --> 10:44.130 Once the certificates are generated they go into the kube-config files 10:44.150 --> 10:45.350 As we discussed earlier. 10:45.350 --> 10:48.290 Well that's it for this lecture in the next lecture. 10:48.290 --> 10:54.200 we will see how you can view certificate information and how certificates are configured by the kubeadm 10:54.210 --> 10:54.590 tool.