1 00:00:00,330 --> 00:00:03,660 Hello and welcome to this lecture in this lecture 2 00:00:03,660 --> 00:00:09,810 We look at how to manage certificates and what the certificate API is in kubernetes. 3 00:00:10,000 --> 00:00:12,690 So what have we done so far. 4 00:00:12,730 --> 00:00:19,510 I as an administrator of the cluster in the process of setting up the whole cluster have set up a CA 5 00:00:19,530 --> 00:00:23,260 server and bunch of certificates for various components. 6 00:00:23,260 --> 00:00:30,090 We then started the services using the right certificates and it's all up and working and the only administrator 7 00:00:30,120 --> 00:00:37,930 and user of the cluster and I have my own admin certificate and key the new admin comes into my team. 8 00:00:37,930 --> 00:00:39,450 She needs access to the cluster. 9 00:00:40,090 --> 00:00:44,830 We need to get her a pair of certificate and key pair for her to access the cluster. 10 00:00:44,950 --> 00:00:51,510 She creates her own private key generates a certificate signing request and sends it to me since I'm 11 00:00:51,550 --> 00:00:52,960 the only admin. 12 00:00:52,990 --> 00:00:59,620 I then takes the certificate signing request to my CA server, gets it signed by the CA using 13 00:00:59,620 --> 00:01:05,160 the CA servers private key and root certificate, thereby generating a certificate and then sends 14 00:01:05,170 --> 00:01:07,810 the certificate back to her. 15 00:01:07,810 --> 00:01:15,480 She now has her own valid pair of certificate and key that she can use to access to cluster the certificates 16 00:01:15,480 --> 00:01:19,570 have a validated period it ends after a period of time. 17 00:01:19,890 --> 00:01:26,220 Every time it expires we follow the same process of generating a new CSR and getting it signed by the 18 00:01:26,220 --> 00:01:26,760 CA. 19 00:01:27,240 --> 00:01:32,930 So we keep rotating the certificate files. So we keep talking about the CA server. 20 00:01:32,970 --> 00:01:37,550 What is the CA serve and where is it located in the Kubernetes setup? The CA 21 00:01:37,540 --> 00:01:42,480 It is really just a pair of key and certificate files we have generated. 22 00:01:42,540 --> 00:01:48,250 Whoever gains access to these pair of files, can sign any certificate for the kubernetes environment. 23 00:01:48,350 --> 00:01:53,130 They can create as many users as they want but whatever privileges they want. 24 00:01:53,130 --> 00:01:58,800 So these files need to be protected and stored in a safe environment say we place them on a server that 25 00:01:58,800 --> 00:02:00,210 is fully secure. 26 00:02:00,330 --> 00:02:07,350 Now that server becomes your CA server. The certificate key file is safely stored in that server and 27 00:02:07,410 --> 00:02:13,110 only on that server every time you want to sign a certificate you can only do it by logging into that 28 00:02:13,110 --> 00:02:14,290 server. 29 00:02:14,310 --> 00:02:19,620 As of now we have the certificates placed on the kubernetes master node itself. So the master node 30 00:02:19,680 --> 00:02:22,330 is also our CA server. 31 00:02:22,580 --> 00:02:24,810 The kubeadm tool does the same thing. 32 00:02:24,840 --> 00:02:29,730 It creates a CA pair of files and stores that on the master node itself. 33 00:02:29,730 --> 00:02:36,150 So far we have been signing requests manually but as and when the users increase and your team grows 34 00:02:36,420 --> 00:02:42,510 you need a better automated way to manage the certificates signing requests as well as to rotate certificates 35 00:02:42,540 --> 00:02:44,100 when they expire. 36 00:02:44,220 --> 00:02:51,570 Kubernetes has a built-in Certificates API that can do this for you. With the Certificates API, you now 37 00:02:51,660 --> 00:02:59,320 send a CertificateSigningRequest directly to kubernetes through an API call. This time, when the administrator 38 00:02:59,320 --> 00:03:04,810 receives a certificate signing request instead of logging onto the master node and signing the certificate 39 00:03:04,810 --> 00:03:05,810 by himself. 40 00:03:05,860 --> 00:03:10,390 he creates a Kubernetes API object called CertificateSigningRequest. 41 00:03:11,230 --> 00:03:17,860 Once the object is created all certificates any requests can be seen by administrators of the cluster. 42 00:03:17,860 --> 00:03:24,720 The request can be reviewed and approved easily using kubectl commands this certificate can then 43 00:03:24,720 --> 00:03:27,330 be extracted and shared with the user. 44 00:03:27,330 --> 00:03:34,500 Let’s see how it is done. A user first creates a key. Then generates a certificate signing request using 45 00:03:34,500 --> 00:03:41,070 using the key with her name in it. Then sends the request to the administrator. The administrator takes the key 46 00:03:41,310 --> 00:03:44,160 and creates a certificatesigningrequest object. 47 00:03:44,160 --> 00:03:49,560 The CertificateSigningRequest is created like any other kuberenetes object using a manifest 48 00:03:49,560 --> 00:03:56,280 file with the usual fields. The kind is CerificateSingingRequest. Under the spec section, specify 49 00:03:56,280 --> 00: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 50 00:04:03,210 --> 00:04:09,360 field is where you specify the certificate signing request sent by the user but you don't specify it 51 00:04:09,390 --> 00:04:17,460 as plain text instead it must be encoded using the base64 command then move the encoded text into the 52 00:04:17,460 --> 00:04:22,160 request field and then submit the request once the object is created. 53 00:04:22,650 --> 00:04:28,200 all certificate signing requests can be seen by administrators by running the kubectl get csr 54 00:04:28,230 --> 00:04:35,070 command. Identify the new request and approve the request by running the kubectl certificate approve 55 00:04:35,090 --> 00:04:41,870 command. Kubernetes signs the certificate using the CA key pairs and generates a certificate for the 56 00:04:41,870 --> 00:04:43,220 user. 57 00:04:43,220 --> 00:04:50,070 This certificate can then be extracted and shared with the user view the certificate by viewing it in 58 00:04:50,070 --> 00:04:58,250 a YAML format. The generate certificate is part of the output. But as before it is in a base64 encoded 59 00:04:58,250 --> 00:05:00,470 format to decode it. 60 00:05:00,560 --> 00:05:05,580 Take the text and use the base 64 utilities decode option. 61 00:05:05,630 --> 00:05:08,810 This gives the certificate in a plain text format. 62 00:05:08,810 --> 00:05:11,230 This can then be shared with the end user. 63 00:05:11,240 --> 00:05:15,290 Now that we have seen how it works let's see who does all of this for us. 64 00:05:15,650 --> 00:05:20,510 If you look at the kubernetes control plane, you see the kube-api server, the scheduler, controller manager, 65 00:05:20,630 --> 00:05:22,070 etcd server etc. 66 00:05:22,310 --> 00:05:28,610 Which of these components is actually responsible for all the certificate related operations all the 67 00:05:28,610 --> 00:05:33,260 certificate related operations are carried out by the controller manager. 68 00:05:33,260 --> 00:05:38,810 If you look closely at the controller or manager you will see that it has controllers in it called as 69 00:05:38,900 --> 00:05:46,630 csr-approving, csr-signing etc that are responsible for carrying out these specific tasks. 70 00:05:46,640 --> 00:05:52,220 We know that if anyone has to sign certificates, they need the CA servers root certificate and private 71 00:05:52,220 --> 00:05:52,970 key. 72 00:05:52,970 --> 00:05:59,620 The controller manager service configuration has two options where you can specify this well that's 73 00:05:59,640 --> 00:06:00,540 for this lecture. 74 00:06:00,540 --> 00:06:04,300 Head over to the practice test and play around with the certificates API. 75 00:06:04,370 --> 00:06:05,940 I will see you in the next lecture.