1 00:00:01,900 --> 00:00:08,420 In this lecture we'll look at how to generate the certificates for the cluster to generate certificates. 2 00:00:08,420 --> 00:00:17,010 there are different tools available such as easyrsa, openssl or cfssl etc or many others. 3 00:00:17,150 --> 00:00:21,940 In this lecture we will use Open SSL tools to generate the certificates. 4 00:00:21,950 --> 00:00:23,270 This is where we left off. 5 00:00:23,300 --> 00:00:25,930 We will start with the CA certificates. 6 00:00:25,940 --> 00:00:33,510 First we create a private key using the openssl command, openssl genrsa –out ca.key. 7 00:00:33,530 --> 00:00:34,370 First we create a private key using the openssl command, openssl genrsa –out ca.key. 8 00:00:34,370 --> 00:00:38,110 Then we use the Open SSL requests command along with the key. 9 00:00:38,110 --> 00:00:44,330 We just created to generate a certificate signing request the certificate signing request is like a 10 00:00:44,330 --> 00:00:50,260 certificate with all of your details but with no signature in the certificate signing request with specified 11 00:00:50,320 --> 00:00:51,650 the name of the component. 12 00:00:51,650 --> 00:00:55,790 this certificate is for in the common name or CN field. 13 00:00:55,820 --> 00:01:00,090 In this case, since we are creating a certificate for the kubernetes CA, we name it 14 00:01:00,110 --> 00:01:08,180 Kubernetes-CA. Finally, we sign the certificate using the openssl x509 command and by specifying 15 00:01:08,180 --> 00:01:12,000 the certificate signing request we generated in the previous command. 16 00:01:12,110 --> 00: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 17 00:01:18,530 --> 00:01:22,640 in the first step. Going forward for all other certificates 18 00:01:22,640 --> 00:01:25,160 we will use this ca key pair to sign them. 19 00:01:25,160 --> 00:01:29,270 The CA now has its private key and root certificate file. 20 00:01:29,290 --> 00:01:29,680 Great. 21 00:01:30,200 --> 00:01:33,400 Let's now look at generating the client's certificates. 22 00:01:33,410 --> 00:01:35,390 We start with the admin user. 23 00:01:35,390 --> 00:01:40,750 We follow the same process where we create a private key for the admin user using the Open SSL command. 24 00:01:40,790 --> 00:01:46,460 We then generate a CSR and that is where we specify the name of the admin user, which is kube-admin. 25 00:01:46,470 --> 00:01:48,230 A quick note about the name. 26 00:01:48,350 --> 00:01:50,410 it doesn’t really have to be kube-admin. 27 00:01:50,510 --> 00:01:51,740 It could be anything. 28 00:01:51,800 --> 00:01:56,100 but remember this is the name that the kubectl client authenticates with 29 00:01:56,180 --> 00:01:58,290 when you run kubectl commands. 30 00:01:58,650 --> 00:02:02,770 So in the audit logs and elsewhere this is the name that you will see. 31 00:02:02,960 --> 00:02:05,670 So provide a relevant name in this field. 32 00:02:05,750 --> 00:02:11,360 Finally, generate a signed certificate using the openssl x509 command. 33 00:02:11,360 --> 00:02:17,210 But this time, you specify the CA certificate and the CA key. You are signing your certificate with the 34 00:02:17,210 --> 00:02:24,740 CA key pair. That makes this a valid certificate within your cluster. The signed certificate is then output 35 00:02:24,770 --> 00:02:31,460 to admin.crt file. That is the certificate that the admin user will use to authenticate to kubernetes 36 00:02:31,470 --> 00:02:32,150 cluster. 37 00:02:32,150 --> 00:02:38,690 If you look at it, this whole process of generating a key and a certificate pair is similar to creating 38 00:02:38,690 --> 00:02:40,890 a user account for a new user. 39 00:02:40,970 --> 00:02:46,520 The certificate is the validated user I.D. and the key is like the password. 40 00:02:46,550 --> 00:02:50,250 It's just that it's much more secure than a simple user name and password. 41 00:02:50,360 --> 00:02:51,980 So this is for the admin user. 42 00:02:52,040 --> 00:02:55,670 How do you differentiate this user from any other users. 43 00:02:55,670 --> 00:03:02,020 The user account needs to be identified as an admin user and not just another basic user. 44 00:03:02,180 --> 00:03:06,380 You do that by adding the group details for the user in the certificate. 45 00:03:06,380 --> 00:03:13,160 In this case a group named SYSTEM:MASTERS exists on kubernetes with administrative privileges. 46 00:03:13,160 --> 00:03:20,060 We will discuss about groups later. But for now its important to know that you must mention this information 47 00:03:20,120 --> 00:03:22,320 in your certificate signing request. 48 00:03:22,370 --> 00:03:28,220 You can do this by adding group details with the OU parameter while generating a signing 49 00:03:28,220 --> 00:03:28,850 request. 50 00:03:28,880 --> 00:03:35,010 Once it's signed we now have our certificate for the admin user with admin privileges. 51 00:03:35,120 --> 00:03:40,280 We follow the same process to generate client certificates for all other components that access the 52 00:03:40,280 --> 00:03:41,480 kube-api server. 53 00:03:41,570 --> 00:03:46,700 The kube-scheduler. Now the kube-scheduler is a system component part of the kubernetes control plane. 54 00:03:47,150 --> 00:03:51,660 So it’s name must be pre-fixed with the key word “system”. 55 00:03:51,660 --> 00:03:56,810 The same with Kube-controller-manager. It is again a system component. So its name must be prefixed with 56 00:03:56,810 --> 00:03:58,230 the keyword system. 57 00:03:58,370 --> 00:04:05,180 And finally kube-proxy. So far we have created CA certificates, then all of the client certificates including 58 00:04:05,180 --> 00:04:08,480 the admin user, scheduler, controller-manager, kube-proxy. 59 00:04:08,690 --> 00:04:13,460 We will follow the same procedure to create the remaining 3 client certificates for the apiservers 60 00:04:13,460 --> 00:04:14,160 and kubelets 61 00:04:14,240 --> 00:04:18,550 When we create the service certificates for them so we will set them aside for now. 62 00:04:18,560 --> 00:04:21,200 Now what do you do with these certificates. 63 00:04:21,200 --> 00:04:24,290 Take the admin certificate for instance to manage the cluster. 64 00:04:24,290 --> 00:04:29,990 You can use the certificate instead of a user and password in a REST API call you make to the 65 00:04:29,990 --> 00:04:36,160 kube-api server. You specify the key the certificate and the ca certificate as options 66 00:04:36,170 --> 00:04:41,810 That's one simple way the other way is to move all of these parameters into a configuration file called 67 00:04:41,810 --> 00:04:42,960 kube-config. 68 00:04:43,100 --> 00:04:48,340 Within that specify the API server endpoint details the certificates to use etc.. 69 00:04:48,440 --> 00:04:53,720 This is what most of the kubernetes clients use. We will look at kube-config in depth in one of 70 00:04:53,720 --> 00:04:54,770 the upcoming lectures. 71 00:04:54,820 --> 00:05:00,260 Okay so we are now left with the server side certificates but before we proceed. 72 00:05:00,320 --> 00:05:01,320 One more thing. 73 00:05:01,430 --> 00:05:07,140 Remember in the pre-requisite lecture we mentioned that for the clients to validate the certificate sent by 74 00:05:07,140 --> 00:05:09,210 the server and vice versa. 75 00:05:09,240 --> 00:05:14,850 They all need a copy of the certificate authorities public certificate the one that we said is already 76 00:05:14,850 --> 00:05:18,900 installed within the user's browsers in case of a web application. 77 00:05:18,900 --> 00:05:23,310 Similarly, in kubernetes for these various components to verify each other, 78 00:05:23,310 --> 00:05:26,430 they all need a copy of the CA’s root certificate. 79 00:05:26,450 --> 00:05:32,260 So whenever you configure a server or a client with certificates you will need to specify the CA 80 00:05:32,270 --> 00:05:33,620 root certificate as well. 81 00:05:33,720 --> 00:05:36,160 Let's look at the service side certificates now. 82 00:05:36,600 --> 00:05:41,640 Let’s start with the ETCD server. We follow the same procedure as before to generate a certificate for 83 00:05:41,640 --> 00:05:42,160 ETCD. 84 00:05:42,480 --> 00:05:48,240 We will name it ETCD-SERVER. ETCD Server can be deployed as a cluster across multiple servers 85 00:05:48,480 --> 00:05:50,530 as in high availability environment. 86 00:05:50,550 --> 00:05:56,340 In that case to secure communication between the different members in the cluster, we must generate additional 87 00:05:56,400 --> 00:06:02,460 peer certificates.Once the certificates are generated specify them while starting the ETCD server. 88 00:06:02,460 --> 00:06:07,440 There are key and cert file options where you specify the etcdserver keys. 89 00:06:07,440 --> 00:06:10,900 There are other options available for specifying the peer certificates. 90 00:06:10,950 --> 00:06:16,710 And finally as we discussed earlier it requires the CA root certificate to verify the clients 91 00:06:16,740 --> 00:06:18,840 connecting to the ETCD server are valid. 92 00:06:18,990 --> 00:06:20,620 Let’s talk about the kube-api server now. 93 00:06:20,630 --> 00:06:28,320 We generate a certificate for the API server like before. But wait, the API server is the most popular 94 00:06:28,320 --> 00:06:31,180 of all components within the cluster. 95 00:06:31,230 --> 00:06:36,340 Everyone talks to the kube-api server. Every operation goes through the kube-api server. 96 00:06:36,420 --> 00:06:40,440 Anything moves within the cluster the API server knows about it. 97 00:06:40,540 --> 00:06:46,980 You need information you talk to the API server and so it goes by many names and aliases within the 98 00:06:46,980 --> 00:06:48,080 cluster. 99 00:06:48,090 --> 00: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 100 00:06:55,560 --> 00:07:02,700 really know what goes under the hoods of kubernetes, the kube-api server IS kubernetes. Others like 101 00:07:02,700 --> 00:07:05,250 like to call it kubernetes.default. 102 00:07:05,640 --> 00:07:11,910 While some refer to it as kubernete.default.svc. And some like to call it by its full name, 103 00:07:12,060 --> 00:07:17,150 kubernetes.default.svc.cluster.local. 104 00:07:17,190 --> 00:07:25,740 Finally, it is also referred to, in some places, simply by its IP address. The IP address of the host running 105 00:07:25,800 --> 00:07:33,150 the kube-api server. Or the pod running it. So all of these names must be present in the certificate 106 00:07:33,300 --> 00:07:39,930 generated for the kube-api server. Only then those referring to kubernetes by these names will 107 00:07:39,930 --> 00:07:46,870 will be able to establish a valid connection. So we use the same set of commands as earlier to generate a 108 00:07:46,870 --> 00:07:54,230 key. In the certificate signing request you specify the name KUBE-APIserver. But how do you specify 109 00:07:54,260 --> 00:07:56,030 all the alternate names. For that 110 00:07:56,030 --> 00:08:03,470 you must create an openssl config file. Create an openssl.cnf file and specify the alternate names 111 00:08:03,470 --> 00:08:05,900 in the alt name section of the file. 112 00:08:05,930 --> 00:08:10,870 Include all the DNS names the API server goes by as well as the IP address. 113 00:08:10,910 --> 00:08:15,200 Pass this config file as an option while generating the certificate signing request. 114 00:08:15,200 --> 00:08:21,530 Finally, sign the certificate using the CA certificate and key. You then have the kube api server certificate. 115 00:08:21,560 --> 00:08:24,820 It is time to look at where we are going to specify these keys. 116 00:08:24,830 --> 00:08:30,350 Remember to consider the apiserver client certificates that are used by the api server while communicating 117 00:08:30,350 --> 00:08:33,350 as a client to the etcd and kubelet servers. 118 00:08:33,350 --> 00:08:39,320 The location of these certificates are passed in to the kube-api servers executable or service configuration 119 00:08:39,320 --> 00:08:40,090 file. 120 00:08:40,310 --> 00:08:46,370 First the CA file needs to be passed in. Remember every component needs the CA certificate to verify 121 00:08:46,370 --> 00:08:47,180 its clients. 122 00:08:47,180 --> 00:08:52,610 Then we provide the apiserver certificates under the tls-cert options. We then specify the client 123 00:08:52,610 --> 00:08:59,180 certificates used by the kube-api server to connect to the etcd server, again with the CA file. And finally 124 00:08:59,470 --> 00:09:03,050 the kube-api server client certificate to connect to the kubelets. 125 00:09:03,050 --> 00:09:10,130 Next comes the kubelet server. The kubelet server is an HTTPS API server that runs on each node, responsible 126 00:09:10,130 --> 00:09:11,430 for managing the node. 127 00:09:11,540 --> 00:09:17,090 That's where the API server talks to to monitor the node as well as any information regarding what pods 128 00:09:17,120 --> 00:09:18,730 to schedule on this node. 129 00:09:18,890 --> 00:09:23,370 As such, you need a key-certificate pair for each node in the cluster. 130 00:09:23,390 --> 00:09:25,700 Now what do you need these certificates. 131 00:09:25,700 --> 00:09:27,810 Are they all going to be named kubelets? 132 00:09:27,960 --> 00:09:28,950 No. 133 00:09:29,360 --> 00:09:34,680 they will be named after their nodes. Node01, node02 and node03 134 00:09:34,700 --> 00:09:36,540 Once the certificates are created. 135 00:09:36,590 --> 00:09:38,810 use them in the kubelet-config file. 136 00:09:38,810 --> 00:09:43,820 As always you specify the root CA certificate. And then provide the kubelet node certificates. 137 00:09:43,820 --> 00:09:47,000 You must do this for each node in the cluster. 138 00:09:47,000 --> 00:09:52,250 We also talked about a set of client certificates that will be used by the kubelet to communicate with 139 00:09:52,250 --> 00:09:53,750 the kube-api server. 140 00:09:53,780 --> 00:09:57,640 These are used by the kubelet to authenticate into the kube-api server. 141 00:09:57,890 --> 00:09:59,900 They need to be generated as well. 142 00:09:59,900 --> 00:10:01,910 What do you name these certificates. 143 00:10:01,910 --> 00:10:08,320 The API server needs to know which node is authenticated and give it the right set of permissions. 144 00:10:08,450 --> 00:10:12,720 So it requires the nodes to have the right names in the right format. 145 00:10:12,740 --> 00:10:18,110 Since the nodes are system components, like the kube-scheduler, and controller-manger we talked about 146 00:10:18,170 --> 00:10:18,800 earlier. 147 00:10:18,800 --> 00:10:24,700 the format starts with the system keyword. Followed by node and then the node name. 148 00:10:24,740 --> 00:10:27,260 In this case node01 to node03. 149 00:10:27,290 --> 00:10:30,500 And how would the api server give it the right set of permissions? 150 00:10:30,500 --> 00:10:35,740 Remember we specified a group name for the admin user so the admin user gets administrative privileges. 151 00:10:35,750 --> 00:10:40,400 Similarly, the nodes must be added to a group named system:nodes. 152 00:10:40,460 --> 00:10:44,130 Once the certificates are generated they go into the kube-config files 153 00:10:44,150 --> 00:10:45,350 As we discussed earlier. 154 00:10:45,350 --> 00:10:48,290 Well that's it for this lecture in the next lecture. 155 00:10:48,290 --> 00:10:54,200 we will see how you can view certificate information and how certificates are configured by the kubeadm 156 00:10:54,210 --> 00:10:54,590 tool.