1 00:00:00,610 --> 00:00:07,000 Hello and welcome to this lecture notes lecture, we look at securing your cabinet, as Closter would 2 00:00:07,000 --> 00:00:08,290 tell us certificate's. 3 00:00:08,740 --> 00:00:15,700 In the previous lecture we saw what public and private keys are, how a server uses public and private 4 00:00:15,700 --> 00:00:17,550 keys to secure connectivity. 5 00:00:17,590 --> 00:00:20,140 We will call them service certificates. 6 00:00:20,770 --> 00:00:23,230 We saw what a certificate authority is. 7 00:00:23,500 --> 00:00:30,130 We learned that the CIA has its own set of public and private keepers that it uses to sign service certificates. 8 00:00:30,550 --> 00:00:32,580 We will call them RWD certificates. 9 00:00:32,890 --> 00:00:39,630 We also saw how a server can request a client to verify themselves using client certificates. 10 00:00:40,150 --> 00:00:46,330 So three types of certificates, several certificates configured on the service road certificate configured 11 00:00:46,330 --> 00:00:51,130 on the ACA servers and then client certificates configured on the clients. 12 00:00:51,310 --> 00:00:54,820 And a quick note on naming convention before we go forward. 13 00:00:55,120 --> 00:01:00,270 You're going to see a lot of certificate files in this lecture and it could be very confusing. 14 00:01:01,060 --> 00:01:04,180 So use this technique to know which one is which. 15 00:01:04,450 --> 00:01:10,180 Usually certificates with public keys are named CRT or pen extension. 16 00:01:10,180 --> 00:01:17,440 So that's server CRT or server not for server certificates or Kleinig CRT or Kleinwort Pen for client 17 00:01:17,440 --> 00:01:18,130 certificates. 18 00:01:18,790 --> 00:01:25,060 And private keys are usually with extension docky or with Hadash Key in the filenames, for example. 19 00:01:25,060 --> 00:01:27,570 Server key, also server dot. 20 00:01:28,750 --> 00:01:35,020 So just remember, private keys have the word key in them, usually either as an extension or in the 21 00:01:35,020 --> 00:01:41,900 name of the certificate and one that doesn't have the word key in them is usually a public key or certificate. 22 00:01:42,370 --> 00:01:43,630 That's how I remember it. 23 00:01:44,560 --> 00:01:48,340 We will now see how these concepts relate to a cabinet as Kluster. 24 00:01:49,710 --> 00:01:56,490 The cabinet is Closter consists of a set of master and worker notes, of course, all communication 25 00:01:56,490 --> 00:02:00,990 between these nodes need to be secure and must be encrypted. 26 00:02:01,480 --> 00:02:06,570 All interactions between all services and their clients need to be secure. 27 00:02:07,410 --> 00:02:12,750 For example, an administrator interacting with the cabinet is clustered through the keep control utility 28 00:02:12,750 --> 00:02:14,250 or via accessing the cabinet. 29 00:02:14,250 --> 00:02:19,050 Is API directly must establish security, close connection. 30 00:02:19,530 --> 00:02:25,140 Communication between all the components within the governor's cluster also need to be secured. 31 00:02:25,770 --> 00:02:31,650 So the two primary requirements are to have all the various services within the cluster to use server 32 00:02:31,650 --> 00:02:37,590 certificates and all clients to use client certificates to verify they are who they say they are. 33 00:02:38,310 --> 00:02:43,590 Let's look at the different components within the Cabinet as cluster and identify the various servers 34 00:02:43,590 --> 00:02:45,480 and clients and who talks to who. 35 00:02:46,200 --> 00:02:48,120 Let's start with the Kubi server. 36 00:02:48,510 --> 00:02:56,010 As we know already, the API server exposes and a service that other components as well as external 37 00:02:56,010 --> 00:02:58,610 users use to manage the companies cluster. 38 00:02:59,280 --> 00:03:04,890 So it is a server and it requires certificates to secure all communication with its clients. 39 00:03:05,550 --> 00:03:07,710 So we generate a certificate and keep here. 40 00:03:07,710 --> 00:03:12,000 We call it API server, DOT CERT and API several darcie. 41 00:03:12,750 --> 00:03:15,900 We will try to stick to this naming convention going forward. 42 00:03:16,500 --> 00:03:22,530 Anything with a CRT extension is the certificate and DOT key extension is the private key. 43 00:03:23,310 --> 00:03:28,740 Also remember, the certificate names could be different in different coroneted setups depending on 44 00:03:28,740 --> 00:03:30,570 who and how the cluster was set up. 45 00:03:30,960 --> 00:03:33,140 So these names may be different in yours. 46 00:03:33,660 --> 00:03:38,970 In this lecture, we will try to use names that help us easily identify the cert files. 47 00:03:39,920 --> 00:03:46,010 Another server in the cluster is the ETSI, the server, the ETSI, the server stores, all the information 48 00:03:46,010 --> 00:03:50,000 about the cluster, so it requires a pair of certificate and key for itself. 49 00:03:50,340 --> 00:03:58,490 We will call it SCD server, DOT, CRT and SCD server that keep the other server component in the cluster 50 00:03:58,490 --> 00:03:59,750 is on the worker nodes. 51 00:04:00,020 --> 00:04:01,580 There are the Kubla services. 52 00:04:01,610 --> 00:04:08,570 They also expose an API endpoint that the Cube API server talks to to interact with the worker nodes. 53 00:04:08,600 --> 00:04:11,540 Again, that requires a certificate and keeper. 54 00:04:11,540 --> 00:04:15,050 We call it Cumulate Dot Sword and Kubelik Key. 55 00:04:16,200 --> 00:04:19,260 Those are really the sole components in the Covenant, is Kloster. 56 00:04:20,400 --> 00:04:26,640 Let's now look at the client components, who are the clients who access the services, the clients 57 00:04:26,640 --> 00:04:29,400 who access the Cuba parts of are us. 58 00:04:29,550 --> 00:04:36,920 The administrators to keep control arrested by the admin user requires a certificate and keeper to authenticate 59 00:04:36,920 --> 00:04:38,170 to the server. 60 00:04:38,580 --> 00:04:42,060 We will call it admin DOT, CRT and admin Darcie. 61 00:04:42,630 --> 00:04:48,670 The scheduler talks to the API server to look for parts that require scheduling and then get the API 62 00:04:48,690 --> 00:04:51,720 server to schedule the parts on the right worker notes. 63 00:04:52,350 --> 00:04:56,040 The scheduler is a client that accesses the API server. 64 00:04:56,220 --> 00:05:02,730 As far as the API server is concerned, the scheduler is just another client, like the admin user. 65 00:05:02,730 --> 00:05:09,330 So the scheduler needs to validate its identity using a client certificate so it needs its own payroll 66 00:05:09,330 --> 00:05:10,770 certificate and keys. 67 00:05:11,290 --> 00:05:14,850 We will call it scheduler Dodsworth and scheduler Key. 68 00:05:15,950 --> 00:05:21,800 The cube controller manager is another client that accesses the Cube API server, so it also requires 69 00:05:21,800 --> 00:05:24,660 a certificate for authentication to the server. 70 00:05:24,710 --> 00:05:26,930 So we create a certificate, prepare for it. 71 00:05:27,910 --> 00:05:34,330 The last client component is the Q proxy, the Q proxy requires a client certificate to authenticate 72 00:05:34,330 --> 00:05:39,240 to the API server and so it requires its own pair of certificate and keys. 73 00:05:39,640 --> 00:05:43,690 We will call them Q proxy DOT CRT and Q Proxy DOT. 74 00:05:43,690 --> 00:05:46,710 Keep the servers communicate amongst them as well. 75 00:05:46,720 --> 00:05:50,840 For example, the API server communicates with the server. 76 00:05:51,130 --> 00:05:57,640 In fact, of all the components, the Cube API server is the only server that talks to the server. 77 00:05:57,820 --> 00:06:04,000 So as far as the server is concerned, the Cube API server is a client, so it needs to authenticate. 78 00:06:04,060 --> 00:06:10,480 The API server can use the same keys that it used earlier for serving its own API service. 79 00:06:11,020 --> 00:06:14,620 The API server, that CRT and the server key files. 80 00:06:14,860 --> 00:06:22,380 Or you can generate a new pair of certificates specifically for the server to authenticate to the server. 81 00:06:23,330 --> 00:06:28,520 The Kubi server also talks to the Kubelik server on each of the individual notes. 82 00:06:28,810 --> 00:06:31,940 That's how it monitors the worker notes for this. 83 00:06:31,950 --> 00:06:37,270 Again, it can use the original certificates or generate new ones specifically for this purpose. 84 00:06:38,470 --> 00:06:40,130 So that's too many certificates. 85 00:06:40,330 --> 00:06:41,390 Let's try and group them. 86 00:06:42,070 --> 00:06:48,190 There are a set of client certificates mostly used by clients to connect to the server, and there are 87 00:06:48,190 --> 00:06:55,840 a set of server side certificates used by the server, SCD server and Kubla to authenticate their clients. 88 00:06:56,650 --> 00:06:59,050 We will now see how to generate these certificates. 89 00:06:59,530 --> 00:07:04,360 As we know already, we need a certificate authority to sign all of these certificates. 90 00:07:04,630 --> 00:07:10,110 Coordinators requires you to have at least one certificate authority for your customer. 91 00:07:10,450 --> 00:07:16,810 In fact, you can have more than one one for all the components in the cluster and another one specifically 92 00:07:16,810 --> 00:07:17,710 for Exelis. 93 00:07:17,950 --> 00:07:24,220 That case, the SCD server certificates and the servers client certificates, which in this case is 94 00:07:24,220 --> 00:07:29,170 the API server client certificate will be all signed by the ETSI, the server servers. 95 00:07:30,400 --> 00:07:33,850 For now, we will stick to just one seet for our customer. 96 00:07:34,330 --> 00:07:34,720 The CI. 97 00:07:34,720 --> 00:07:38,890 A. as we know, has its own pair of certificate and key. 98 00:07:39,550 --> 00:07:43,270 We will call it see a dog and see a dot key. 99 00:07:44,390 --> 00:07:47,390 That should sum up all the certificates used in the cluster.