In this video we're going to learn how to create a secret inside of a Cuban 80s cluster.
So here's the command we're going to run Cuba's GTL create secret generic than the name of the secret.
Then dash dash from literal equals.
Then the key that we want to set and the value for it.
Couple of notes on this.
First off the word generic right here.
There are different kinds of secrets we can create intranets is an example of a different kind of secret
we can create is some information related to accessing a repository of Docker images.
That is a different kind of secret.
We are creating a generic secret which means this is just a all purpose kind of secret piece of information
the name of the secret.
Right here is very similar to the names we assign to pods or deployments.
This is mostly used for logging purposes but in the case of a secret we also use this to refer to inside
of a pod config file you'll see an example that very shortly over here on the right hand side we can
assign many different properties or many different key value pairs into a secret.
In this case we are saying one key value pair of Jason Webb token or JWT equals a SDF and there's another
note I want to give you here.
This is an example of an imperative command in Cuban edits imperative commands are where we run a command
to to rate an actual object for everything else we've done in Cuba and so far we have not used an imperative
approach where we run commands to directly create objects.
Instead we used a more declarative approach where we wrote out a config file and then applied that config
file.
The reason that we are using this imperative approach right here is because we don't really want to
have a config file that lists out the value of our secrets.
We don't necessarily have to list out the value of a secret inside the config file.
We can technically use a local environment variable on your machine and then refer to that from the
config file.
And so that would still allow us to have a more declarative approach.
So this is just a very easy way of creating a secret.
The one downside to it is that anytime you start to create or spin up a new cluster you are going to
have to remember all the different secrets that you had created over time.
So even though this is very easy to run right now it does not require us to create a config file or
set up some local environment variable or anything like that.
There is a cost to pay down the line as we have to remember the different secrets now what I do personally.
I have never I'm working on a cluster and I'm creating secrets manually in this style.
I will essentially just take this exact command right here and story in some very very secure location.
I usually do not really do that for production deployments.
Instead I will write out that or take that config file approach.
But for a development or a staging or a test environment I will usually just kind of copy paste this
somewhere else in a very secure location.
I'm not going to tell you where I store it in particular.
You could do some research on your own and just throw the command over there.
So any time I need to remember all the different secrets that exists I can just go and reference that
file.
OK.
So let's go over to our terminal.
We are going to run that command back over here.
We'll do a cube Seitel and then create secret generic
well then put down the name of the secrets which is JWT dash secret then dash dash from literal and
then our key value pair we want to set inside of here.
So on this diagram I said JWT is a SDF that's probably not a great key value pair just because it's
implying that the value of JWT is a SDF maybe a better thing to use here or be something like Jeb U
W T E or something like that equals SDF.
That B might be a little bit more clear but can do JWT underscore E equals SDF naturally in reality
you probably want to use a string here.
Way more complicated than SDF do you might want to do something like that but for me in a development
environment SDF is just fine okay.
So now the secret is created.
We can always get a list of all the different secrets that exist inside of our cluster by doing a QC
tell it secrets.
And so you'll see in my case I've got a couple of secrets that already exist such as stripe a Postgres
password and the one that we just created two seconds ago.
OK so now we've created that secret.
We need to somehow get it into our pods.
So we need to take the information so that secret and set it on the enviroment variables for each of
our different pods to do so we're going to open up our pod config file or more precisely our deployment
config file.
We're going to add in some options to our pod configuration spec that's going to tell communities that
whenever it creates this pod we want to find the secret get that JWT underscore piece of information
and assign it to the set of environment variables that are peer inside of that container so let's go
and find our deployment config file that is inside of our in Fred rectory off dash devil.
So this is the only God that we're creating right now through this deployment so we need to somehow
reference that secret and tell Cooper 90s to include it as an environment variable inside of this container
right here to do so right after image.
We're gonna throw in a new line and put in an end section EMV.
This is short for environment variable.
So this is where we're going to list out all the different environment variables we want to have access
to inside of this container.
This is going to be an array so going to put down a single Dash.
Right now we're going to have just a single entry I'm going to put in a name property.
This is going to be the name of the environment variable as it shows up inside of that container.
So when we start up our off application name right here is going to be the property on our set of environment
variables that we're going to access inside of our off at for us.
We'll just stay very consistent.
We're going to use a name of J.W. key to underscore key
then we're going to tell Cuban entities that we want the value for this enviroment variable to come
from the secret that we just created.
So we will write out value from secret key ref which is short for reference.
Well then list out the name of the secret to the name of the secret that we just created was JWT dash
secret so put in JWT dash secret and then the key inside there.
So remember inside of a secret we can have many different key value pairs.
We just used a key of JWT to underscore key.
So we want to look up this key value pair and give us the value for it.
So for keyhole but in JWT we like so much should be it.
It's all now safe.
This I going to go back over to my terminal take a look at scaffold and I'll see that a change was made
to my off deployment.
Now I do want to show you something really really interesting very quickly.
This is something that might help you out in the line really quick back inside of another terminal window.
I'm gonna do a cube Seitel.
Get pods and I'll see that.
Yep.
My pod is running right there I'm now going to go backwards that same config file and I encourage you
not to do this.
This is just a very quick example.
I'm gonna find the secret key ref I'm gonna find the name of the secret we want to load up and I'm gonna
change it to gibberish.
So this is a reference to a key that does not exist inside of our cluster.
I'm then going to save this what makeover if I go to scaffold I'll see that.
Hey.
All right.
Looks like the deployment was configured but I got an error right here from something.
Who knows what's actually throwing this there that says secret blah blah blah.
Not found little bit more interesting than that little error though.
If I go and do another QCT I'll get pods.
I'm going to get a another pod right here for our off deployment that has a status of rate container
config air to debug this.
We would do a describe statement or run the described command on this pod.
I'll do a cube Seitel describe pod and then put in the name of the pod that I want to describe when
I run that.
I then get the air that says secret blah blah blah not found.
So it turns out that if you tried to load a secret or references secret inside of a pod that doesn't
exist.
Cuban eddies is just going to not start up that port.
This is just like I said something to keep in mind because I've ran into this issue every now and then
where I will try to deploy something new.
I'll then get a create container config error and I say to myself what's going on here.
And so you do the describe and it turns out you might have made a typo in the name of the secret.
All right.
I'm going to revert that change back to JWT dash secret.
So now if I save this I should build a flip back over.
Take a look at scaffold again.
Looks like there's still an issue here.
I'm not really gonna sweat that too much if I do a cube C.T. I'll get pods.
Yeah that's better.
So looks like everything is back to running as expected.
OK.
So we have now created our secret.
We have bound it to a very specific container.
And the last thing we have to do is go into the application that's running inside of that container
and make sure that we start to reference that environment variable called JWT underscore key.
So let's take care of that in just a moment.