WEBVTT 00:01.136 --> 00:01.969 Instructor: In this section, 00:01.969 --> 00:03.240 we're going to start putting together our config 00:03.240 --> 00:05.160 for the issuer object. 00:05.160 --> 00:07.950 This is going to be another configuration file, very much 00:07.950 --> 00:10.530 like all the others we have previously put together. 00:10.530 --> 00:11.910 So inside of my code editor, 00:11.910 --> 00:14.640 I'll find my K Eights directory, and inside there 00:14.640 --> 00:19.640 I'm going to make a new file called issuer.yaml. 00:19.890 --> 00:22.950 Again, the purpose of the issuer file is to describe 00:22.950 --> 00:26.490 to our cert manager exactly where it should go 00:26.490 --> 00:29.010 in attempt to get a certificate. 00:29.010 --> 00:31.620 Now, just like many other config files we've put together 00:31.620 --> 00:33.903 we're going to have an API version. 00:35.070 --> 00:37.710 We're going to specify a API version here 00:37.710 --> 00:41.070 very dissimilar to any other that we've put together so far. 00:41.070 --> 00:46.070 We'll say certmanager.k eights.io/v1 alpha 1. 00:48.570 --> 00:50.400 Now the reason for this very different 00:50.400 --> 00:51.840 API version right here, 00:51.840 --> 00:54.660 remember that the API version is essentially specifying 00:54.660 --> 00:56.640 a bucket of different object types. 00:56.640 --> 00:58.680 So we can pull from, we've said 00:58.680 --> 01:01.110 that we're going to make an object of type issuer 01:01.110 --> 01:03.420 and that is definitely not an object that is included 01:03.420 --> 01:05.490 in Kubernetes by default. 01:05.490 --> 01:07.440 It is something that is defined specifically 01:07.440 --> 01:09.870 by the cert manager that we just installed. 01:09.870 --> 01:11.610 So for the API version, we're saying 01:11.610 --> 01:15.150 reach into the cert manager bucket of objects. 01:15.150 --> 01:18.153 We want to be able to create a issuer type object. 01:20.880 --> 01:23.580 So on the next line we'll define our kind of object 01:23.580 --> 01:25.893 which is going to be a cluster issuer. 01:27.660 --> 01:30.990 We'll then put down our metadata tag and give this a name. 01:30.990 --> 01:33.900 We're going to name it after the source for the issuer. 01:33.900 --> 01:37.560 So the purpose of this issuer is to tell our cert manager 01:37.560 --> 01:39.930 to reach out to Let's Encrypt 01:39.930 --> 01:43.590 and specifically the production version of Let's Encrypt. 01:43.590 --> 01:45.487 So we're going to give this a name of 01:45.487 --> 01:48.843 "Let's Encrypt - Prod", like so. 01:50.880 --> 01:53.190 After that we'll put down a spec. 01:53.190 --> 01:55.473 This is gonna have an entry of acme. 01:56.640 --> 01:59.220 We'll then specify this server that Cert Manager 01:59.220 --> 02:01.290 should reach out to when it tries to establish 02:01.290 --> 02:03.180 this verification process. 02:03.180 --> 02:06.570 So this is essentially a link to the Let's Encrypt API 02:06.570 --> 02:08.250 that's going to be used for setting up 02:08.250 --> 02:10.650 all this different communication back and forth. 02:10.650 --> 02:13.920 So this is going to be a hard coded URL right here. 02:13.920 --> 02:17.223 We're going to do "https", notice the S on there, 02:18.390 --> 02:23.390 pull in "//acme-vo2.api.letsencrypt.org/directory", like so. 02:36.000 --> 02:37.500 Now after that, we're going to put 02:37.500 --> 02:40.320 in our personal email address. 02:40.320 --> 02:42.240 Now the email is not actually used as part 02:42.240 --> 02:44.220 of this verification or anything like that. 02:44.220 --> 02:46.620 Let Encrypt says that they have to have your email 02:46.620 --> 02:49.920 on hand just for whatever purposes they decide. 02:49.920 --> 02:51.780 So we're not gonna actually get any emails or anything 02:51.780 --> 02:53.730 like that or have to respond to anything. 02:53.730 --> 02:55.020 Nonetheless, I still do recommend 02:55.020 --> 02:57.810 that you put in your real email address. 02:57.810 --> 02:59.610 So for my email inside of a string, 02:59.610 --> 03:03.303 I'll put my email like so. 03:05.100 --> 03:06.810 Next up, we're going to define something called 03:06.810 --> 03:10.800 a private key secret ref 03:10.800 --> 03:15.243 and we'll give it a value of name Let's Encrypt fraud. 03:16.410 --> 03:18.480 All right, so the private key secret ref right here 03:18.480 --> 03:21.750 is not at all connected to the secret that is generated 03:21.750 --> 03:23.200 as a part of the certificate. 03:24.060 --> 03:24.893 It turns out that 03:24.893 --> 03:27.210 behind the scenes when your Kubernetes cluster 03:27.210 --> 03:29.850 is going to eventually communicate with Let's Encrypt, 03:29.850 --> 03:32.880 during this process at some stage, Let's Encrypt sends 03:32.880 --> 03:35.610 over a little secret key that is tied to 03:35.610 --> 03:38.460 essentially your record with Let's Encrypt. 03:38.460 --> 03:39.600 And it actually comes into play 03:39.600 --> 03:42.450 as a part of this verification process right here. 03:42.450 --> 03:45.420 It's actually used to essentially decide exactly 03:45.420 --> 03:48.390 how to respond when Let's Encrypt tries to access 03:48.390 --> 03:50.850 this randomly generated URL. 03:50.850 --> 03:53.250 It's this little key that gets sent back to us 03:53.250 --> 03:55.110 and stored inside of the secret key ref 03:55.110 --> 03:57.270 is not actually something we ever have to use. 03:57.270 --> 03:59.130 So essentially we just kind of throw it on here 03:59.130 --> 04:00.303 and forget about it. 04:01.650 --> 04:05.050 Now the last last option we'll put on is HTTP01 04:07.080 --> 04:11.278 and we're gonna put a set of curly braces like so. 04:11.278 --> 04:14.580 Now this probably looks like a real weird option right here. 04:14.580 --> 04:17.040 So all this option is doing is saying we want to 04:17.040 --> 04:20.880 use this HTTP process of obtaining a certificate. 04:20.880 --> 04:23.580 We want to reach out to Let's Encrypt and say, 04:23.580 --> 04:25.200 'Hey, I want a certificate'. 04:25.200 --> 04:27.840 Let's Encrypt says, 'Okay, respond on this route'. 04:27.840 --> 04:29.400 And then we eventually do. 04:29.400 --> 04:31.290 That's all this little configuration line right here 04:31.290 --> 04:32.250 is doing. 04:32.250 --> 04:33.930 There's actually another different way 04:33.930 --> 04:35.700 of obtaining a certificate or going through 04:35.700 --> 04:39.030 this verification process that is a little bit different 04:39.030 --> 04:41.490 than the HTTP one that we're putting together right now. 04:41.490 --> 04:44.100 But without a doubt, setting up the HTTP version 04:44.100 --> 04:45.150 is a lot easier 04:45.150 --> 04:47.883 than the other DNS option that is available. 04:49.230 --> 04:50.310 All right, so that's pretty much it. 04:50.310 --> 04:51.690 That's all we have to put together inside 04:51.690 --> 04:53.790 of our issuer.yaml file. 04:53.790 --> 04:56.880 So I'm going to save this file and I'll close it out. 04:56.880 --> 04:58.500 We're gonna take a little pause 04:58.500 --> 05:00.270 and then in the next section we're going to 05:00.270 --> 05:03.510 start putting together our config file 05:03.510 --> 05:05.250 for our certificate as well. 05:05.250 --> 05:07.613 It's a quick break and I'll see you in just a minute.