Welcome back everybody.
So currently we have a containerized MongoDB database, which by default does not require authentication
such that any service is able to seamlessly connect to MongoDB and save data to it without providing
any credentials, without authenticating, without providing a username or password.
This is not very good.
We need to secure our database such that only select users are able to access it.
All right now, by default, Mongo's configuration requires no authentication for access.
So if we don't configure MongoDB to require authentication, then it will allow anybody to access it
and write data to it.
However, um, MongoDB, the app itself, it does expect to environment variables mongo init db root
username and mongo init db root password.
If you don't give it these variables.
It just assumes that you don't want to enforce authentication.
But if our container if the container provides its underlying MongoDB app with the environment variables
that it needs to set up authentication, then the application will be instrumented to only allow um
services that provide the correct username and password to read and write data to it.
All right.
So let's go ahead and ensure that the container provides its underlying MongoDB app with the environment
variables that it needs in order to set up authentication.
So we're going to make sure that the MongoDB application only allows people with the username admin
to be able to read and write data, and that username needs to come with a password.
Equal to password one two, three.
So the container has given its underlying MongoDB app.
These environment variables MongoDB expects these environment variables.
It's going to know how to use them to set up authentication.
And now what I want to do is say kubectl delete deployments, stateful sets um PVCs dash dash all dash
n great submission.
All right.
We want to start off on a clean slate.
By deleting the PVC its associated PV.
Assuming we have the delete reclaim policy, which I'm pretty sure we do by default should be deleted
as well.
Okay.
So starting off on a clean slate.
And now for the great submission API instead of stateless V2.
We're going to load in the Great Submission API v3.
So this API I programmed to authenticate to a database that requires authentication.
So let's go ahead and load in v3.
And v3 requires four environment variables the MongoDB host and port which directs the request to the
cluster IP service.
And upon the container getting its hands on the request.
We need to also provide a MongoDB user and password inside the connection string.
So the first one is MongoDB user.
The application needs to connect to the database with a username of admin.
All right
And the username Must have a password.
A password 123.
All right, so we've set up our MongoDB app to require these credentials.
And we've set up our great submission API v3 to include these credentials inside of the connection string.
All right.
Let's go ahead and try it out.
Actually you know what.
Let me by giving the wrong password we'll say password 1234.
And then we'll say kubectl apply f.
Okay I'm going to say kubectl get pods dash n.
Great submission.
And pod still terminating two pods trying to run
The great submission portal is ready.
The great submission APIs are running, but they're not ready because the readiness probe probably tried
to talk to the readiness endpoint.
The readiness endpoint is probably sending back a status of 503 because we weren't able to connect.
We probably weren't able to authenticate.
Let's verify this.
Kubectl logs dash f.
We're going to get the logs for one of the pods right over here dash n.
Great submission.
Authentication failed.
Okay beautiful.
At least it's trying to authenticate.
So what's happening is the host and port that we injected that leads the request to the cluster IP service.
Ultimately forwarding it to MongoDB at its container port.
MongoDB gets access to the entire request.
It looks at the username and password within the connection string.
The connection string was formatted in a way that MongoDB can understand.
It sees that the password is incorrect and rejects the connection.
I programmed the app to always try to connect over and over, which is why you'll see that it keeps
saying authentication failed.
So let's go ahead and give it a proper password.
Okay.
We'll try this again.
Kubectl get pods dash n great submission.
Give it some time.
All right.
Beautiful.
We've got one.
We've got two out of two.
Great submission.
API is running.
These are terminating.
We are golden.
So now we actually have a MongoDB database that enforces authentication.
And a stateless great submission API that authenticates against a database.
How do we make sure this all works?
Let's try to submit a grade using the grade submission portal so Harry will give him a score of 54.
So because we deleted the PVC, thereby deleting the PVC, it's bound to, we should have no more data.
So we'll submit data from scratch.
The grade submission portal is going to send this payload to the Grade Submission API, which will try
to save it to the MongoDB DB database.
If everything works out and there's no bottleneck anywhere, we should experience a smooth user experience.
And indeed we do.
All right, that's pretty much it.
I'll give Hermione a grade, make sure everything is working properly.
Hermione, give her a score of 99 and arithmancy.
All right.
Now what I can do is go back and make sure that everything is actually persisting to a persistent volume
so I can delete all the pods Kubectl delete pods.
Dash n great submission.
Dash dash all.
And while this is deleting, I just want to mention that whether you're using MySQL or PostgreSQL,
regardless of what the database is, the environment variables that you use to set the credentials will
vary.
You just got to go on the documentation and figure out what variables the application expects, and
inject them accordingly.
All this is is a stateful app that expects environment variables to direct it, to tell it what to do,
and everything's been deleted, which means everything has now been recreated courtesy of the stateful
set and the deployment managing everything for us.
So kubectl get pods, dash and great submission.
Everything is back because the data that we saved is in a durable, persistent volume, and the MongoDB
zero stateful pod was probably reattached to A to the PVC, therefore regaining access to all of its
original data.
So if I refresh grades, we see all the grades that we originally saved.
Beautiful, persistent volumes at work.
Now there is another thing I want to mention, and this is a perfect segue into the next section.
Usually passwords are way more secure than password one two, three.
Okay, usually you've got special characters, but the problem is that some special characters in YAML,
they have a meaning, so you can't just write them in plain text.
Does that mean that we're limited to what types of passwords we can put?
Well, that's the thing you should never mix.
Um, configuration.
So application specific settings and parameters with deployment details.
We're doing that all throughout.
We've got uh, configuration mixed with deployment details.
Okay.
Uh we're doing that here as well.
We've got configuration mixed with deployment details.
The problem when you entangle configuration and deployment is your deployment manifests become really,
really hard to maintain.
Uh, things become very inflexible, very rigid, just as you saw here.
We're limited as to what type of password we can use.
So you never want to mix configuration with environment specific information.
We need to separate them.
And that's exactly what the topic of the next section will be when we discuss configmaps and secrets
I'll see you in the next one.