WEBVTT 00:00.720 --> 00:01.553 -: In the last section, 00:01.553 --> 00:04.140 we installed cert manager into our Kubernetes cluster. 00:04.140 --> 00:05.880 We're now gonna briefly discuss exactly 00:05.880 --> 00:08.340 what we have to create to integrate cert manager 00:08.340 --> 00:11.880 into our project and get it working the way we expect. 00:11.880 --> 00:13.263 So a couple diagrams here. 00:15.690 --> 00:16.920 Here we go. 00:16.920 --> 00:20.070 So in this diagram at the very center is cert manager. 00:20.070 --> 00:21.630 As you just saw when we installed it, 00:21.630 --> 00:24.810 it created a deployment, which in turn created a pod. 00:24.810 --> 00:26.220 There's also a service account 00:26.220 --> 00:28.260 and a cluster roll binding in there as well 00:28.260 --> 00:30.330 which essentially gave that pod the ability 00:30.330 --> 00:31.980 to manipulate our cluster 00:31.980 --> 00:34.440 and create different resources inside of it. 00:34.440 --> 00:36.900 So cert manager by itself, you can really just think of 00:36.900 --> 00:40.200 as essentially being a pod that is going to reach out 00:40.200 --> 00:42.930 to our cluster and kind of mess around with things. 00:42.930 --> 00:44.340 And then at some point in time, 00:44.340 --> 00:46.680 it's gonna set up a route handler to respond 00:46.680 --> 00:49.860 to the Let's Encrypt verification request. 00:49.860 --> 00:52.050 Now, in order to get cert manager working the way 00:52.050 --> 00:53.070 that it expects, 00:53.070 --> 00:55.710 there are two different objects that we have to create 00:55.710 --> 00:59.370 with two different config files inside of our project. 00:59.370 --> 01:01.860 So these are two types of objects that we're gonna create 01:01.860 --> 01:03.270 and the same way that we've created 01:03.270 --> 01:05.043 many other objects before. 01:05.940 --> 01:07.650 We'll talk about the issuer first 01:07.650 --> 01:09.900 over here on the right hand side. 01:09.900 --> 01:12.360 The issuer is going to be a config file 01:12.360 --> 01:15.060 that's going to tell the cert manager how to reach out 01:15.060 --> 01:18.840 to a certificate authority and obtain a certificate. 01:18.840 --> 01:21.840 So in our case, we are using a certificate authority 01:21.840 --> 01:24.990 or essentially an entity who issues certificates 01:24.990 --> 01:26.700 of Let's Encrypt. 01:26.700 --> 01:29.670 Let's Encrypt publishes some public APIs 01:29.670 --> 01:32.130 and API addresses to access those 01:32.130 --> 01:34.230 out for you to read very easily. 01:34.230 --> 01:36.720 So we're going to create this issuer object 01:36.720 --> 01:39.900 that says essentially we want to use Let's Encrypt 01:39.900 --> 01:42.480 and here's the address to the API to use 01:42.480 --> 01:45.510 to initiate this entire exchange process. 01:45.510 --> 01:47.280 So that's the purpose of the issuer. 01:47.280 --> 01:49.680 It's just telling cert manager where to go 01:49.680 --> 01:53.790 to attempt to initiate this verification process. 01:53.790 --> 01:55.680 The reason that we create this in an object 01:55.680 --> 01:57.270 is that cert manager is set up 01:57.270 --> 02:00.300 to allow you to define several different issuers. 02:00.300 --> 02:02.100 And even if you're using Let's Encrypt, 02:02.100 --> 02:04.650 you might want to have more than one issuer. 02:04.650 --> 02:06.690 For example, with Let's Encrypt, 02:06.690 --> 02:09.630 you get the ability to connect to a staging server 02:09.630 --> 02:13.170 or essentially kind of a practice version of Let's Encrypt. 02:13.170 --> 02:15.810 So for example, if you're not sure that this entire flow 02:15.810 --> 02:17.700 is going to work the way that you expect, 02:17.700 --> 02:20.490 you would access the staging version or essentially 02:20.490 --> 02:23.640 the practice version of Let's Encrypt before eventually 02:23.640 --> 02:26.430 moving over to the real production version 02:26.430 --> 02:27.390 of Let's Encrypt 02:27.390 --> 02:30.480 when you eventually want to get your certificate. 02:30.480 --> 02:33.300 So that's why we were able to create multiple issuers. 02:33.300 --> 02:35.940 Now for us, I'm pretty confident 02:35.940 --> 02:40.140 that everything's gonna work correctly the first time maybe. 02:40.140 --> 02:42.090 So we're not gonna create multiple issuers. 02:42.090 --> 02:43.290 We're gonna create just the one, 02:43.290 --> 02:46.110 and we're going to go directly to Let's Encrypt production 02:46.110 --> 02:47.430 the first time around. 02:47.430 --> 02:50.490 Honestly, if you use staging, that staging workaround 02:50.490 --> 02:52.920 with NGINX ingress like we are, 02:52.920 --> 02:55.410 life actually gets more confusing than you would think 02:55.410 --> 02:58.260 so it's kind of better to just access the production version 02:58.260 --> 03:00.030 of Let's Encrypt first time around, 03:00.030 --> 03:02.640 rather than trying to use the staging version 03:02.640 --> 03:05.103 and then flip over to production later on. 03:05.970 --> 03:08.160 Now, the other object that we need to create again 03:08.160 --> 03:09.570 with the config file 03:09.570 --> 03:12.120 is going to be something called a certificate. 03:12.120 --> 03:14.610 The certificate is going to have some information 03:14.610 --> 03:16.710 that details the exact nature 03:16.710 --> 03:19.380 of the certificate that we want to obtain. 03:19.380 --> 03:22.050 So whenever you get a TLS certificate 03:22.050 --> 03:25.320 such as the one I'm using, or the one that draw.io uses 03:25.320 --> 03:29.850 which is this diagramming tool that I am using right now, 03:29.850 --> 03:31.680 if you look at the certificate right here, 03:31.680 --> 03:33.480 you'll see that it has some information 03:33.480 --> 03:38.220 in the details section like who draw.io is. 03:38.220 --> 03:40.200 So it looks like it's issued by CloudFlare. 03:40.200 --> 03:41.550 There's some other information on here 03:41.550 --> 03:44.670 about location and issued by blah, blah, blah. 03:44.670 --> 03:46.140 Essentially, there's a lot of information 03:46.140 --> 03:47.760 tied to the certificate. 03:47.760 --> 03:50.130 So the purpose of this certificate object file 03:50.130 --> 03:52.080 or the config file is to say 03:52.080 --> 03:54.450 here is the domain name that we want to use 03:54.450 --> 03:55.620 for this certificate. 03:55.620 --> 03:58.350 It'll also have some information about maybe subdomain 03:58.350 --> 04:00.690 so we want to register under the certificate as well. 04:00.690 --> 04:03.240 And just in general, it's going to describe the nature 04:03.240 --> 04:05.850 of the certificate that we want to get. 04:05.850 --> 04:09.480 The certificate is also going to define a Kubernetes secret. 04:09.480 --> 04:12.633 Remember, we use a secret to store secret information. 04:13.830 --> 04:16.620 Now the certificate gets a little bit relevant later on 04:16.620 --> 04:18.990 so let's continue walking through this flow. 04:18.990 --> 04:21.750 So we're going to create the certificate and the issuer 04:21.750 --> 04:24.390 and then we're going to not necessarily feed them 04:24.390 --> 04:25.590 into the cert manager. 04:25.590 --> 04:28.290 The cert manager is actually going to automatically see 04:28.290 --> 04:31.050 that we have created a certificate and an issuer. 04:31.050 --> 04:33.300 Once it sees that both of these have been created, 04:33.300 --> 04:36.150 it's then going to initiate that exchange process 04:36.150 --> 04:37.830 with Let's Encrypt. 04:37.830 --> 04:41.280 Let's Encrypt is going to eventually issue a certificate. 04:41.280 --> 04:44.490 So once that cert manager gets the certificate 04:44.490 --> 04:46.830 from Let's Encrypt, it then needs to store it 04:46.830 --> 04:49.290 somewhere inside of our Kubernetes cluster. 04:49.290 --> 04:50.580 And that's the purpose of the secret 04:50.580 --> 04:52.950 that got created over here by the certificate. 04:52.950 --> 04:54.990 So just to be clear, you and I are not going 04:54.990 --> 04:58.200 to create the secret in the same way that we did previously. 04:58.200 --> 05:00.720 So we're not gonna run QCTL create secret 05:00.720 --> 05:01.680 or anything like that. 05:01.680 --> 05:03.390 We're going to instead put an entry 05:03.390 --> 05:05.820 into the certificate configuration file 05:05.820 --> 05:08.490 that says hey certificate, when you get created, 05:08.490 --> 05:09.780 you should make a secret 05:09.780 --> 05:11.910 called something, something, something. 05:11.910 --> 05:15.300 And the secret will be created for us automatically. 05:15.300 --> 05:16.830 Now, once we get that certificate 05:16.830 --> 05:19.200 and stored inside the secret, the last thing 05:19.200 --> 05:23.340 we'll have to do is reconfigure our NGINX ingress. 05:23.340 --> 05:25.080 So we're going to make a little change 05:25.080 --> 05:27.330 to that configuration file for our ingress 05:27.330 --> 05:28.740 and we're going to tell it hey, 05:28.740 --> 05:31.650 you should now start serving up HTTPS traffic. 05:31.650 --> 05:33.870 And by the way, here is a secret 05:33.870 --> 05:37.080 that is holding the certificate that you need to use. 05:37.080 --> 05:39.480 So that's pretty much the overview of what we have to do. 05:39.480 --> 05:42.330 We have to create this certificate, the issuer, 05:42.330 --> 05:43.620 and then we have to do a little bit 05:43.620 --> 05:46.950 of a reconfiguration on our NGINX ingress. 05:46.950 --> 05:48.360 So let's take a quick pause right here. 05:48.360 --> 05:51.030 When we come back in the next section, we'll get started 05:51.030 --> 05:55.530 by working on our issuer config file to start. 05:55.530 --> 05:57.980 So quick pause and I'll see you in just a minute.