‫So now let's talk about AWS KMS
‫which is the 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 the 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 secrets 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 the 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 used when you have encrypt/decrypt,
‫or sign/verify type of operations.
‫And in that case, you can download the public key
‫out of KMS, but you cannot 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 types of KMS keys.
‫The first one are AWS owned keys.
‫They're free and this is the kind of key you would use
‫when you use SSE-S3 type of encryption
‫or SSE-DynamoDB where you have the option, for example,
‫that you choose a key owned by DynamoDB.
‫So these are not really KMS because
‫you don't really see them,
‫but they're types of encryption keys within AWS.
‫Then you have the AWS-managed keys, and they're free,
‫and you will recognize them because they start
‫with AWS, slash, and then the service name.
‫For example aws/rds or aws/ebs,
‫or in this example aws/dynamodb.
‫They're free and you can just use them as you please
‫but only from within the service that it's assigned to.
‫Then you have your own customer-managed keys,
‫and they're custom keys, and they cost you $1 per month.
‫And if you want to import them as well,
‫you can import them and they cost you $1 per month.
‫KMS also has a pricing where you're going to pay
‫for each API call made it to the KMS service,
‫which is about 3 cents per 10,000 API calls.
‫You also have automatic key rotation.
‫So if it's an AWS-managed KMS key
‫then it's automatic, every 1 year.
‫And if it's a customer managed key that you've created
‫from within KMS, then you must enable
‫automatic rotation, and it's every 1 year.
‫And if it's imported KMS key
‫then you can only manually rotate it.
‫And for this you need to leverage an alias.
‫So KMS key 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 ASWS S3 bucket policy
‫with a difference that if you don't have a 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 role 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 account 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 account, and we're done.
‫So that's a lot of information by KMS,
‫but let's go into hands-on to hopefully
‫learn a bit more about it.