Hello and welcome to this lecture on secrets in Kubernetes. Here we have a simple python web application
that connects to a mysql database. On success
the application displays a successful message.
If you look closely into the code you will see the hostname username and password hardcoded.
This is of course not a good idea.
As we learned in the previous lecture, one option would be to move these values into a configMap. The
configMap stores configuration data in plain text format.
So while it would be okay to move the hostname and username into a configMap it is definitely not
the right place to store a password.
This is where secrets coming secrets are used to store sensitive information like passwords or keys.
They're similar to configMap except that they're stored in an encoded or hashed format as with config
maps.
There are two steps involved in working with secrets.
First create the secret and second injected into pod.
There are two ways of creating a secret.
The imperative way - without using a Secret definition file and the Declarative way by using a Secret
definition file with the imperative method.
You can directly specify the key value pairs in the command line itself to create a secret of the given
values, run the kubectl create secret generic command.
The command is followed by the secret name and the option –from-literal. The from literal option is used to
specify the key value pairs in the command itself.
In this example, we are creating a secret by the name app-secret, with a key value pair
DB_Host=mysql. If you wish to add additional key value pairs, simply specify the from literal
options multiple times however this could get complicated when you have too many secrets to pass in
another way to input the secret data is through a file.
Use the –from-file option to specify a path to the file that contains the required data.
The data from this file is read and stored under the name of the file let us now look at the declarative
approach.
For this we create a definition file, just like how we did for the ConfigMap.
The file has apiVersion, kind, metadata and data. The apiVersion is v1, kind is Secret. Under metadata specify
the name of the secret.
We will call it app-secret. Under data add the secret data in a key-value format.
However one thing we discussed about secrets was that there used to store sensitive data and are stored
in an encoded format.
Here we have specified the data in plain text which is not very safe.
So while creating a secret with a declarative approach you must specify the secret values in a hashed
format.
So you must specify the data in an encoded form like this.
But how do you convert the data from plain text to an encoded format on a linux host from the command.
echo –n followed by the text you are trying to convert, which is mysql in this case and pipe
that to the base64 utility. To view secrets run the kubectl get secrets command. This lists
the newly created secret along with another secret previously created by kubernetes for its internal
purposes to view more information on the newly created secret.
run the kubectl describe secret command.
This shows the attributes in the secret but hides the value themselves to view the values as well.
run the kubectl get secret command with the output displayed in a YAML format using the
–o option.
You can now see the hashed values as well.
Now how do you decode these hashed values.
Use the same base64 Command used earlier to encode it but this time add a decode option to it.
Now that we have secret created let us proceed with step 2 configuring it with a pod.
Here I have a simple pod definition file that runs my application.
To inject an environment variable, add a new property to the container called envFrom. The envFrom
property is a list so we can pass as many environment variables as required each item in the list corresponds
to a secret item.
Specify the name of the secret we created earlier.
Creating the pod definition file now makes the data in the secret available as environment variables
for the application.
What we just saw was injecting secrets as environment variables into the PODs.
There are other ways to inject secret into PODs.
You can inject as single environment variables or inject the whole secret as files in a volume if you
were to mount the secret as a volume in the pod.
Each attribute in the secret is created as a file with the value of the secret as its content.
In this case since we have three attributes in our secret three files are created and if we look at
the contents of the D.B. password file we see the password in it.
That's it for this lecture.
Head over to the coding exercises and practice working with secrets.