WEBVTT 00:00.330 --> 00:03.660 Hello and welcome to this lecture in this lecture 00:03.660 --> 00:09.810 We look at how to manage certificates and what the certificate API is in kubernetes. 00:10.000 --> 00:12.690 So what have we done so far. 00:12.730 --> 00:19.510 I as an administrator of the cluster in the process of setting up the whole cluster have set up a CA 00:19.530 --> 00:23.260 server and bunch of certificates for various components. 00:23.260 --> 00:30.090 We then started the services using the right certificates and it's all up and working and the only administrator 00:30.120 --> 00:37.930 and user of the cluster and I have my own admin certificate and key the new admin comes into my team. 00:37.930 --> 00:39.450 She needs access to the cluster. 00:40.090 --> 00:44.830 We need to get her a pair of certificate and key pair for her to access the cluster. 00:44.950 --> 00:51.510 She creates her own private key generates a certificate signing request and sends it to me since I'm 00:51.550 --> 00:52.960 the only admin. 00:52.990 --> 00:59.620 I then takes the certificate signing request to my CA server, gets it signed by the CA using 00:59.620 --> 01:05.160 the CA servers private key and root certificate, thereby generating a certificate and then sends 01:05.170 --> 01:07.810 the certificate back to her. 01:07.810 --> 01:15.480 She now has her own valid pair of certificate and key that she can use to access to cluster the certificates 01:15.480 --> 01:19.570 have a validated period it ends after a period of time. 01:19.890 --> 01:26.220 Every time it expires we follow the same process of generating a new CSR and getting it signed by the 01:26.220 --> 01:26.760 CA. 01:27.240 --> 01:32.930 So we keep rotating the certificate files. So we keep talking about the CA server. 01:32.970 --> 01:37.550 What is the CA serve and where is it located in the Kubernetes setup? The CA 01:37.540 --> 01:42.480 It is really just a pair of key and certificate files we have generated. 01:42.540 --> 01:48.250 Whoever gains access to these pair of files, can sign any certificate for the kubernetes environment. 01:48.350 --> 01:53.130 They can create as many users as they want but whatever privileges they want. 01:53.130 --> 01:58.800 So these files need to be protected and stored in a safe environment say we place them on a server that 01:58.800 --> 02:00.210 is fully secure. 02:00.330 --> 02:07.350 Now that server becomes your CA server. The certificate key file is safely stored in that server and 02:07.410 --> 02:13.110 only on that server every time you want to sign a certificate you can only do it by logging into that 02:13.110 --> 02:14.290 server. 02:14.310 --> 02:19.620 As of now we have the certificates placed on the kubernetes master node itself. So the master node 02:19.680 --> 02:22.330 is also our CA server. 02:22.580 --> 02:24.810 The kubeadm tool does the same thing. 02:24.840 --> 02:29.730 It creates a CA pair of files and stores that on the master node itself. 02:29.730 --> 02:36.150 So far we have been signing requests manually but as and when the users increase and your team grows 02:36.420 --> 02:42.510 you need a better automated way to manage the certificates signing requests as well as to rotate certificates 02:42.540 --> 02:44.100 when they expire. 02:44.220 --> 02:51.570 Kubernetes has a built-in Certificates API that can do this for you. With the Certificates API, you now 02:51.660 --> 02:59.320 send a CertificateSigningRequest directly to kubernetes through an API call. This time, when the administrator 02:59.320 --> 03:04.810 receives a certificate signing request instead of logging onto the master node and signing the certificate 03:04.810 --> 03:05.810 by himself. 03:05.860 --> 03:10.390 he creates a Kubernetes API object called CertificateSigningRequest. 03:11.230 --> 03:17.860 Once the object is created all certificates any requests can be seen by administrators of the cluster. 03:17.860 --> 03:24.720 The request can be reviewed and approved easily using kubectl commands this certificate can then 03:24.720 --> 03:27.330 be extracted and shared with the user. 03:27.330 --> 03:34.500 Let’s see how it is done. A user first creates a key. Then generates a certificate signing request using 03:34.500 --> 03:41.070 using the key with her name in it. Then sends the request to the administrator. The administrator takes the key 03:41.310 --> 03:44.160 and creates a certificatesigningrequest object. 03:44.160 --> 03:49.560 The CertificateSigningRequest is created like any other kuberenetes object using a manifest 03:49.560 --> 03:56.280 file with the usual fields. The kind is CerificateSingingRequest. Under the spec section, specify 03:56.280 --> 04:03.210 the groups the user should be part of and list the usages of the account as a list of strings the request 04:03.210 --> 04:09.360 field is where you specify the certificate signing request sent by the user but you don't specify it 04:09.390 --> 04:17.460 as plain text instead it must be encoded using the base64 command then move the encoded text into the 04:17.460 --> 04:22.160 request field and then submit the request once the object is created. 04:22.650 --> 04:28.200 all certificate signing requests can be seen by administrators by running the kubectl get csr 04:28.230 --> 04:35.070 command. Identify the new request and approve the request by running the kubectl certificate approve 04:35.090 --> 04:41.870 command. Kubernetes signs the certificate using the CA key pairs and generates a certificate for the 04:41.870 --> 04:43.220 user. 04:43.220 --> 04:50.070 This certificate can then be extracted and shared with the user view the certificate by viewing it in 04:50.070 --> 04:58.250 a YAML format. The generate certificate is part of the output. But as before it is in a base64 encoded 04:58.250 --> 05:00.470 format to decode it. 05:00.560 --> 05:05.580 Take the text and use the base 64 utilities decode option. 05:05.630 --> 05:08.810 This gives the certificate in a plain text format. 05:08.810 --> 05:11.230 This can then be shared with the end user. 05:11.240 --> 05:15.290 Now that we have seen how it works let's see who does all of this for us. 05:15.650 --> 05:20.510 If you look at the kubernetes control plane, you see the kube-api server, the scheduler, controller manager, 05:20.630 --> 05:22.070 etcd server etc. 05:22.310 --> 05:28.610 Which of these components is actually responsible for all the certificate related operations all the 05:28.610 --> 05:33.260 certificate related operations are carried out by the controller manager. 05:33.260 --> 05:38.810 If you look closely at the controller or manager you will see that it has controllers in it called as 05:38.900 --> 05:46.630 csr-approving, csr-signing etc that are responsible for carrying out these specific tasks. 05:46.640 --> 05:52.220 We know that if anyone has to sign certificates, they need the CA servers root certificate and private 05:52.220 --> 05:52.970 key. 05:52.970 --> 05:59.620 The controller manager service configuration has two options where you can specify this well that's 05:59.640 --> 06:00.540 for this lecture. 06:00.540 --> 06:04.300 Head over to the practice test and play around with the certificates API. 06:04.370 --> 06:05.940 I will see you in the next lecture.