So now let's talk about AWS KMS,
which is a key management service of AWS.
So we've been using it, you know, a lot without knowing
but anytime you hear encryption
when you have an AWS service,
it's most likely going to be KMS encryption.
The aim is that with this KMS service
AWS is going to manage the encryption keys for us.
And that's great
because that means that we have less things to do.
So KMS is of course fully integrated
with IAM, for authorization.
And it gives us very easy ways
to control access to our data if it's encrypted with KMS.
The power of using AWS KMS is that you're able to audit
every single API call made
to use your keys through CloudTrail,
which is something the exam may test you on.
So on top of it,
KMS can be used seamlessly into most AWS services.
So for example, if you wanted to encrypt the data
at rest in an EBS volume, just enable the KMS integration,
same for S3, same for RDS, same for SSM,
and same for pretty much all the services
that require encryption.
The idea is that with KMS, you can also use it yourself.
And if you have secret data
you never ever store them in plain text,
that means just as is, especially in your code.
So if you want to use KMS
you can also use KMS through API calls.
You can use the AWS CLI or the SDK.
And that means that you can encrypt
whatever is a secret for you with a KMS key,
and then these encrypted secrets can be, for example
stored in your code or in environment variables.
That is a much better pattern.
So now let's talk about the different types
of KMS keys available to you.
So now it's called the KMS key,
by the way, it used to be called
a KMS customer master key, but it was confusing
because there's also the customer-managed keys
as we'll see in a second.
So now we just talk about KMS keys.
So we have two types of KMS keys.
We have the symmetric KMS keys,
and that means there's only one single encryption key
that is used to encrypt and decrypt data.
And so any service of AWS that is integrated
with KMS will use symmetric keys.
The idea is that when we create or use a KMS symmetric key
then we never get access to the key itself, okay?
All we do is that we use the KMS API calls
to leverage and use that key.
The second kind of key available on KMS
are called asymmetric keys.
That means that you have two keys.
You have a public key.
That's used to encrypt data
and a private key used to decrypt data.
So this is used when you have Encrypt/Decrypt
or Sing/Verify type of operations.
And in that case, you can download the public key
out of KMS, but you cannot use access the private key.
You can only use API calls again
to access the private key.
So the use cases for an asymmetric type of key
is when you want the encryption to be done
outside of your AWS cloud
by users who cannot, or don't have access to the KMS API key
in which case they will use the public key
to encrypt the data, send it over to you
and you within your account,
you will use the private key of AWS to decrypt that data.
So within the world of KMS keys, you have different kinds.
You have the AWS managed keys
and they will be named for example, aws/rds or aws/ebs.
So they're free to use,
and they're really well integrated
with these services and they're free
so they are managed by AWS and you can use them
to encrypt at rest for a specific service,
but you can also decide to create your own
Customer Managed Key CMK and you create them within KMS
and it costs you a dollar per month per key.
Or you can also decide to import your own key material
into KMS with versus creating it from within KMS.
And this will cost you as well, $1 per month.
On top of it, you will pay
for every API call you make to KMS,
so it's around 3 cents per 10,000 API calls.
You can set up automatic key rotation
for your keys for security.
So if you are using the AWS managed key
then it's automatic,
it happens every one year.
And if you're using your customer-managed KMS key
you must enable it.
And you, if you do enable it
you have it automatically happen every one year,
you cannot change the frequency.
If you decide to import your own key material into KMS
then you can only do manual rotation of keys,
and you must also use what's called a KMS key alias
to do the rotation correctly.
So KMS keys are scoped per region.
That means that if we have an EBS volume
encrypted with KMS key in a region, for example, eu-west-2,
then if you want to copy that to a different region
we have to do several steps.
First of all, we have to take a snapshot of this EBS volume.
And if we take a snapshot from an encrypted snapshot
then this snapshot itself will also be encrypted
with the same KMS key.
Then to copy the snapshot to another region,
we need to re-encrypt the snapshot
using a different KMS key.
And this is something AWS will do for you
but the same KMS key, cannot live in two regions.
So now we have an EBS snapshot,
it's encrypted with KMS with a different key
and it lives in another region.
Now we restore the snapshot into its own EBS volume
with KMS, and it's KMS key B into the region ap-southeast-2.
Now, the other thing we need to know about
is KMS key policies.
So this is to control access to your KMS keys.
It's similar to an S3 bucket policy with a difference
that if you don't have the KMS key policy on your KMS key
then no one can access it.
So in that regards, we have two types of KMS key policies.
We have the default one,
and it's created if you don't provide
a specific custom KMS key policy.
And the idea is that the default allows everyone
in your account to access this key.
That means that if you have an IAM policy allowing a user
or all to access this key policy, you're good.
But if you wanted to have more specific controls over it
you could use a KMS key policy that is custom
in which you define the users,
the roles that can access your KMS key.
And you define who can administer the key.
And this is especially helpful
if you want to do cross account access for your KMS key,
because we can authorize another account to use our KMS key.
So when do we use this?
Well, for example, if we wanted to copy
an encrypted snapshots across accounts.
So we create a snapshot encrypted with our own KMS key
and it's a customer-managed key,
it must be that
because we need to attach a custom key policy,
and then we attach a KMS key policy to authorize
for cross-account access.
It looks like this.
Then we share the encrypted snapshot
with the target accounts.
And then in the target accounts, we create a copy
of the snapshot and we encrypt it
with a different customer-managed key
in that target account.
And then we can create a volume
from the snapshot in the target accounts and we're done.
So that's a lot of information about KMS,
but let's go into hands on
to hopefully learn a bit more about it.