Let's go through the lab four secrets.
The first question is,
how many secrets exist on the system in the default namespace?
We're going to do a kubectl get secrets.
There's just one, so the answer is one.
How many secrets are defined in the default-token secret?
We're going to do a kubectl describe secret,
and with the additional details.
Under the data section, we have multiple details.
We have the ca.crt. That's one.
Then you have the namespace, and then you have the token.
This entire text here
is the encoded token, so we have three.
That's the answer for that.
Now, what is the type of the default-token secret?
The type, as you can see,
it is a kubernetes.io/service-account-token.
That's the type.
Which of the following is not a secret data
defined in the default-token?
We know that the data is ca.crt, namespace, and token.
That's namespace, ca.crt, and token.
Type is not a data.
That's the answer to that.
We're going to deploy an application with the below architecture.
We have already deployed the required pods and services.
Check out the pods and services created,
and check out the web application using the Webapp MySQ link above.
Let's first check out the deployment.
There are no deployments.
Let's check pods.
There are two pods.
You have a webapp pod and a MySQL pod.
You have the MySQL pod, and this is the webapp pod.
Then there are two services.
Let's check services.
This window is a default Kubernetes service,
but you also have the webapp service, which happens to be this,
and the SQL01
and SQL01 service,
which happens to be this.
Those are the services.
Then secret.
There's a default token secret,
but that's not the secret that's used here.
The secret is required for the webapp application
to connect to the MySQL database.
Let's check the application status.
Here, we can see that it's in a failed state.
It says failed connecting to the MySQL database.
The database host is not set, the DB is not set,
and the password is not set.
That's the error.
Let's proceed.
The reason the application has failed
is because we have not created the secret object yet.
Let's create a new secret named db-secret
with the data given below.
Let's create a secret.
kubectl create secret
and let's quickly check the help.
When you create a secret, you have to specify the type of secret.
We're not going to create a Docker registry or TLS.
We're just going to create a generic secret.
Let's check the help for that.
Here, we see
the syntax we use to create a secret is to specify secret generic
and then the name of the secret followed by the data from a file,
or it could be from multiple files,
or it could just be from literal
just from the command line.
We're going to use this approach
because we have the information right here.
Let's do that.
Secret generics, don't forget generic.
The name of the secret is db-secret,
and then we have from-literal
=DB_Host=sql01.
Then from literal again,
DB_User=root.
Now, remember that these are case-sensitive.
Then from literal again and DB_
password equals password123.
Let's verify if it's created.
Describe DB secret.
Describe secret,
then DB secret.
We see that it's created with the data DB_Host,
DB_ User, and DB_Password.
That's a success.
Next is to configure a webapp-pod
to load environment variables from the newly created secret.
Let's check pod out first.
We have the webapp pod
and currently, there are no secrets
so let's edit the pod.
To add the secret, but if we don't know how to do that,
let's first review the Kubernetes documentation pages
and look at secrets.
Let's go to the first one.
We are at the page for secrets.
Here, as you can read,
you must not create secret as we created just now
to store database credentials or passwords.
That's because the secret data is stored in etcd as is
without any encryption.
Anyone who has access to the API server
or the etcd database can read or even modify the secret.
Must be enabling encryption at rest
or look into enabling role-based access controls.
Let's go ahead and find information on configuring the secret for the pod.
You can see that here.
Here you have using a secret
and then you also have using secrets as environment variables.
There are multiple options here.
Here's one that we could use,
which is the envFrom what we did for the config map.
We could use the envFrom, and then specify a secret key reference,
that way, all the data stored in the secret
is going to be passed through as environment variable.
Let's copy that.
This is going to go into the container section.
We can have this anywhere.
Space that.
The key name should be db-secret.
Let's save the file.
I'm going to allow us to edit it.
That's fine.
We're going to quit and let's do a kubectl replace force
and specify the file.
We'll just wait for the pod to be deleted and recreated.
Okay. That's done.
Let's verify the pod.
We see that the environment variables are right from the db-secret.
Okay, let's check this out.
That's configured correctly.
Let's go back and review the web application
and we see that is now a success.
It's able to read the environment variables
as we passed through.
Of course, remember we should not read passwords and display like this,
but this is a sample application
to prove how secrets can be passed as environment variables
and this helps us debug if something is not passed through right.
That's the end of this lab.