Narrator: So let's talk about the AWS Parameter Store.
And so to me this is one of the most revolutionary service.
It's underutilized by people and you should know about it
because the exams starts asking questions.
So it's a way to securely store your configuration
and your secrets.
Think as what the name indicates, it's a Parameter Store.
You have the option to use something called seamless
encryption, and so you can use KMS to basically encrypt any
configuration you put in the Parameter Store.
As such, Parameter Store is a really good way
to put database passwords somewhere.
It's Serverless so you don't have to measure any servers.
It's scalable.
You can have tens of thousands of parameters.
It's durable.
You don't need to worry about the parameters going away.
It's free and there's a really easy SDK
to use it as we'll see in the hands on lecture.
On top of things, you're about to do version tracking
of configurations and secrets, so if you erase
a secret database password from a new one to an old one,
you're still able to access for example,
the old data base secrets which is really good.
You can get all the configuration through IAM,
and all the secrets are under a path.
I'll show you what that means in the next slide.
But so that means that using IAM, you can restrict who can
view which database passwords and on top of it,
because there is KMS integration, you also need to define
KMS policies to allow someone to decrypt a secret.
You can get notified of anything happening for example,
secrets changing or parameters changing using
the CloudWatch Events.
And finally there is an integration with CloudFormation
just in case you would need to have Parameter Store
feed into your CloudFormation template.
So here's what it looks like visually.
Here's your application and it can be whatever you want.
It could be EC2, it could be Linda, it could be your
computer, it could be the CLI.
And so it wants to interact with the Parameter Store.
So it wants to retrieve parameters.
So what we can do is that we can just use the SDK and say
"Hey Parameter Store, I'd like to get
a plain text configuration."
Now what happens is that the Parameter Store will go
and check with IAM that I have the right to access that
parameter and the configuration.
And so if it's plain text, just fine,
it will just send it back.
But the second use case is to use encrypted configuration.
So likewise we will ask Parameter Store,
"Hey, we want this encrypted configuration."
It will check the IAM permissions that we have
and if they are okay, it will also call the
decryption service on KMS side.
So KMS will be used to decrypt it and Parameter Store.
If everything is fine, will send us back the configuration.
And so that's pretty good because we don't need to directly
interact with KMS to retrieve some encrypted data.
We just interact with SSM and the decryption happens
seamlessly for us.
So it simplifies a little bit the work flow versus KMS.
If there's a hierarchy, here's what the parameters look
like, so for example, and your free to name it
however you want.
For example you have my department, and in my department
you have my app.
You have the dev environment and under dev you have the
database url and the database password.
We may have a prod environment under which you have
a database url and database password,
so they're the same hierarchy.
But we can have other apps under my department
and we could have other departments.
So think of like a giant tree and you can organize
that tree however you want.
Some people have a department centrics, some people
have a app centrics, some people have
a environment centric.
All that matters is that you define some kind of
hierarchy and convention by how you define your parameters.
So why do we do this?
Well say we have a Dev Lambda Function and we want
to get Dev Parameters then we would just use the
GetParamaters or GetParametersByPath API.
So just remember these two API's.
And we would ask directly for the Dev Parameters.
But if we had a Prod Lambda Function, it would
automatically ask for the Prod Parameters.
And so here we can see we can differentiate different
parameters for different environments.
Which is good because we have clear separation
of duties and roles and et cetera, et cetera.
So this is how easy that is, to be honest.
You just need to remember that the stores are a hierarchy,
that you get encrypted and plain texts parameters
and that you have GetParametersByPath or GetParameters.
That's it.
We're just going to practice this in the next lecture,
just so you get a much better idea of how it works
because this is one of these services that you need
to see how it works to get a better idea
of how things go.
But you'll see it's very easy and I find
it incredibly useful.
So see you in the next lecture.