WEBVTT 00:00.050 --> 00:01.010 Welcome back everybody. 00:01.010 --> 00:08.900 So currently we have a containerized MongoDB database, which by default does not require authentication 00:08.990 --> 00:17.990 such that any service is able to seamlessly connect to MongoDB and save data to it without providing 00:17.990 --> 00:23.060 any credentials, without authenticating, without providing a username or password. 00:23.150 --> 00:24.440 This is not very good. 00:24.440 --> 00:31.130 We need to secure our database such that only select users are able to access it. 00:31.520 --> 00:38.390 All right now, by default, Mongo's configuration requires no authentication for access. 00:38.390 --> 00:45.530 So if we don't configure MongoDB to require authentication, then it will allow anybody to access it 00:45.530 --> 00:47.300 and write data to it. 00:47.330 --> 00:56.810 However, um, MongoDB, the app itself, it does expect to environment variables mongo init db root 00:56.810 --> 00:59.960 username and mongo init db root password. 00:59.990 --> 01:02.590 If you don't give it these variables. 01:02.590 --> 01:06.670 It just assumes that you don't want to enforce authentication. 01:06.670 --> 01:14.020 But if our container if the container provides its underlying MongoDB app with the environment variables 01:14.020 --> 01:21.130 that it needs to set up authentication, then the application will be instrumented to only allow um 01:21.160 --> 01:27.640 services that provide the correct username and password to read and write data to it. 01:27.790 --> 01:28.600 All right. 01:28.600 --> 01:38.200 So let's go ahead and ensure that the container provides its underlying MongoDB app with the environment 01:38.200 --> 01:42.550 variables that it needs in order to set up authentication. 01:42.970 --> 01:52.660 So we're going to make sure that the MongoDB application only allows people with the username admin 01:54.160 --> 02:02.470 to be able to read and write data, and that username needs to come with a password. 02:07.500 --> 02:09.720 Equal to password one two, three. 02:09.960 --> 02:14.070 So the container has given its underlying MongoDB app. 02:14.100 --> 02:19.440 These environment variables MongoDB expects these environment variables. 02:19.440 --> 02:22.650 It's going to know how to use them to set up authentication. 02:23.910 --> 02:38.070 And now what I want to do is say kubectl delete deployments, stateful sets um PVCs dash dash all dash 02:38.070 --> 02:39.450 n great submission. 02:40.950 --> 02:41.580 All right. 02:41.580 --> 02:44.040 We want to start off on a clean slate. 02:47.370 --> 02:51.060 By deleting the PVC its associated PV. 02:51.210 --> 02:56.580 Assuming we have the delete reclaim policy, which I'm pretty sure we do by default should be deleted 02:56.580 --> 02:57.120 as well. 02:57.150 --> 02:57.630 Okay. 02:57.660 --> 03:00.330 So starting off on a clean slate. 03:00.510 --> 03:05.660 And now for the great submission API instead of stateless V2. 03:05.780 --> 03:09.170 We're going to load in the Great Submission API v3. 03:09.200 --> 03:18.650 So this API I programmed to authenticate to a database that requires authentication. 03:18.650 --> 03:24.290 So let's go ahead and load in v3. 03:25.490 --> 03:33.830 And v3 requires four environment variables the MongoDB host and port which directs the request to the 03:33.830 --> 03:35.390 cluster IP service. 03:35.390 --> 03:39.020 And upon the container getting its hands on the request. 03:39.020 --> 03:46.220 We need to also provide a MongoDB user and password inside the connection string. 03:46.220 --> 03:49.220 So the first one is MongoDB user. 03:49.310 --> 03:57.410 The application needs to connect to the database with a username of admin. 03:58.940 --> 03:59.900 All right 04:02.960 --> 04:07.120 And the username Must have a password. 04:10.120 --> 04:12.070 A password 123. 04:15.880 --> 04:22.960 All right, so we've set up our MongoDB app to require these credentials. 04:22.960 --> 04:32.410 And we've set up our great submission API v3 to include these credentials inside of the connection string. 04:32.440 --> 04:32.980 All right. 04:32.980 --> 04:34.600 Let's go ahead and try it out. 04:34.630 --> 04:35.830 Actually you know what. 04:35.860 --> 04:40.300 Let me by giving the wrong password we'll say password 1234. 04:40.570 --> 04:43.420 And then we'll say kubectl apply f. 04:46.390 --> 04:52.690 Okay I'm going to say kubectl get pods dash n. 04:52.690 --> 04:54.250 Great submission. 04:57.730 --> 05:02.230 And pod still terminating two pods trying to run 05:04.750 --> 05:06.750 The great submission portal is ready. 05:06.750 --> 05:15.090 The great submission APIs are running, but they're not ready because the readiness probe probably tried 05:15.090 --> 05:18.600 to talk to the readiness endpoint. 05:18.630 --> 05:24.810 The readiness endpoint is probably sending back a status of 503 because we weren't able to connect. 05:24.840 --> 05:27.450 We probably weren't able to authenticate. 05:27.480 --> 05:28.920 Let's verify this. 05:28.920 --> 05:31.170 Kubectl logs dash f. 05:31.170 --> 05:35.610 We're going to get the logs for one of the pods right over here dash n. 05:35.610 --> 05:37.020 Great submission. 05:38.340 --> 05:40.410 Authentication failed. 05:40.440 --> 05:41.850 Okay beautiful. 05:41.880 --> 05:44.520 At least it's trying to authenticate. 05:44.520 --> 05:52.860 So what's happening is the host and port that we injected that leads the request to the cluster IP service. 05:52.890 --> 05:57.480 Ultimately forwarding it to MongoDB at its container port. 05:57.510 --> 06:00.780 MongoDB gets access to the entire request. 06:00.780 --> 06:04.350 It looks at the username and password within the connection string. 06:04.350 --> 06:08.180 The connection string was formatted in a way that MongoDB can understand. 06:08.210 --> 06:12.620 It sees that the password is incorrect and rejects the connection. 06:12.650 --> 06:18.440 I programmed the app to always try to connect over and over, which is why you'll see that it keeps 06:18.440 --> 06:19.610 saying authentication failed. 06:19.610 --> 06:22.430 So let's go ahead and give it a proper password. 06:26.510 --> 06:26.810 Okay. 06:26.810 --> 06:28.340 We'll try this again. 06:30.680 --> 06:33.830 Kubectl get pods dash n great submission. 06:33.920 --> 06:35.480 Give it some time. 06:42.470 --> 06:42.830 All right. 06:42.860 --> 06:43.220 Beautiful. 06:43.250 --> 06:44.270 We've got one. 06:44.300 --> 06:45.890 We've got two out of two. 06:45.920 --> 06:46.790 Great submission. 06:46.820 --> 06:47.990 API is running. 06:47.990 --> 06:49.370 These are terminating. 06:49.370 --> 06:51.200 We are golden. 06:51.200 --> 06:57.980 So now we actually have a MongoDB database that enforces authentication. 06:57.980 --> 07:06.230 And a stateless great submission API that authenticates against a database. 07:06.260 --> 07:08.900 How do we make sure this all works? 07:10.530 --> 07:18.120 Let's try to submit a grade using the grade submission portal so Harry will give him a score of 54. 07:18.120 --> 07:24.330 So because we deleted the PVC, thereby deleting the PVC, it's bound to, we should have no more data. 07:24.330 --> 07:27.210 So we'll submit data from scratch. 07:27.210 --> 07:33.270 The grade submission portal is going to send this payload to the Grade Submission API, which will try 07:33.270 --> 07:36.840 to save it to the MongoDB DB database. 07:36.870 --> 07:44.550 If everything works out and there's no bottleneck anywhere, we should experience a smooth user experience. 07:45.870 --> 07:47.160 And indeed we do. 07:47.190 --> 07:50.310 All right, that's pretty much it. 07:50.310 --> 07:55.380 I'll give Hermione a grade, make sure everything is working properly. 07:55.410 --> 07:59.190 Hermione, give her a score of 99 and arithmancy. 08:00.090 --> 08:01.530 All right. 08:01.710 --> 08:08.100 Now what I can do is go back and make sure that everything is actually persisting to a persistent volume 08:08.100 --> 08:11.810 so I can delete all the pods Kubectl delete pods. 08:11.960 --> 08:14.720 Dash n great submission. 08:15.920 --> 08:17.480 Dash dash all. 08:23.420 --> 08:29.390 And while this is deleting, I just want to mention that whether you're using MySQL or PostgreSQL, 08:29.420 --> 08:36.110 regardless of what the database is, the environment variables that you use to set the credentials will 08:36.110 --> 08:36.980 vary. 08:37.010 --> 08:45.050 You just got to go on the documentation and figure out what variables the application expects, and 08:45.080 --> 08:46.670 inject them accordingly. 08:46.700 --> 08:53.450 All this is is a stateful app that expects environment variables to direct it, to tell it what to do, 08:54.440 --> 09:01.820 and everything's been deleted, which means everything has now been recreated courtesy of the stateful 09:01.820 --> 09:05.060 set and the deployment managing everything for us. 09:05.060 --> 09:08.900 So kubectl get pods, dash and great submission. 09:10.310 --> 09:18.670 Everything is back because the data that we saved is in a durable, persistent volume, and the MongoDB 09:18.700 --> 09:25.630 zero stateful pod was probably reattached to A to the PVC, therefore regaining access to all of its 09:25.630 --> 09:26.350 original data. 09:26.350 --> 09:31.960 So if I refresh grades, we see all the grades that we originally saved. 09:31.960 --> 09:34.510 Beautiful, persistent volumes at work. 09:34.540 --> 09:40.690 Now there is another thing I want to mention, and this is a perfect segue into the next section. 09:40.720 --> 09:46.330 Usually passwords are way more secure than password one two, three. 09:46.360 --> 09:53.890 Okay, usually you've got special characters, but the problem is that some special characters in YAML, 09:53.890 --> 09:59.140 they have a meaning, so you can't just write them in plain text. 09:59.710 --> 10:06.310 Does that mean that we're limited to what types of passwords we can put? 10:06.940 --> 10:11.410 Well, that's the thing you should never mix. 10:11.880 --> 10:13.950 Um, configuration. 10:13.950 --> 10:20.850 So application specific settings and parameters with deployment details. 10:20.940 --> 10:23.190 We're doing that all throughout. 10:23.190 --> 10:28.950 We've got uh, configuration mixed with deployment details. 10:28.980 --> 10:29.820 Okay. 10:30.240 --> 10:31.740 Uh we're doing that here as well. 10:31.740 --> 10:36.090 We've got configuration mixed with deployment details. 10:36.090 --> 10:44.460 The problem when you entangle configuration and deployment is your deployment manifests become really, 10:44.460 --> 10:46.200 really hard to maintain. 10:46.230 --> 10:51.960 Uh, things become very inflexible, very rigid, just as you saw here. 10:51.960 --> 10:55.770 We're limited as to what type of password we can use. 10:55.770 --> 11:02.610 So you never want to mix configuration with environment specific information. 11:02.670 --> 11:04.260 We need to separate them. 11:04.260 --> 11:10.590 And that's exactly what the topic of the next section will be when we discuss configmaps and secrets 11:10.620 --> 11:12.360 I'll see you in the next one.