Encrypt everything Link to heading
Encryption has been available from quite a while, but the Snowden revelations about the Global surveillance program back in 2013 started an informal movement to encrypt everything.
AWS CTO Werner Vogels has been vocal about it on nearly every re:invent or AWS Summit in the last couple of years, and he is notorious with his encrypted T-shirts:
.jpg "Werner Vogels - Encrypt Everything, Web Summit 2019, CC BY 2.0, Wikipedia Commons")
What is AWS Key Management System (KMS)? Link to heading
I’m not going to retell the AWS KMS documentation but we need to define it, before we can get into the details on when to choose the different key options.
So, in general, KMS is the AWS managed service that helps you to easily create and control the keys you use for cryptographic operations. It provides a highly available solution for key generation, storage, management, and auditing for you to encrypt your data and control who has access to both the data and the encryption keys.
What’s the difference between AWS-managed and customer-managed Custom Master Keys? Link to heading
In general, there are two main types of KMS Customer Master Keys (CMKs)
- AWS Managed Keys - they are created automatically for you within your AWS account, whenever you enable or start using encryption for another AWS service or resource like S3. If you create an s3 bucket and enable encryption for it, AWS will automatically create the SSE-S3 KMS key in the account in which that bucket was created. This key is unique for the AWS account and region in which it has been created. And it could be used only by the respective service for which it was created.
- Customer Managed Keys - they are created at your request and can configured to better suite your use case
We will outline the key differences in the table below (based on the table in the official docs}:
| CMKs | AWS-managed | Customer-managed |
|---|---|---|
| who creates the key | AWS creates the key on user’s behalf | explicitly generated by the customer |
| who rotates the key | automatically rotated by AWS every three years | Rotated every year if the customer enables rotation |
| who deletes the key | can’t be deleted | can be deleted by the customer |
| what’s the scope of the key | limited to the service for which it was created | can be used by multiple services, based on it’s resource policy |
| who manages the resource policy and controls the access to the key | AWS-managed, there is a policy but it can’t be changed by the customer | Customer managed via KMS/IAM policy |
| who can use the key | Every user os service that has access to KMS granted by it’s IAM policy | Every user or service that has access to KMS granted by it’s IAM policy, unless it’s forbidden by the KMS policy |
When should we use Customer Managed KMS CMKs? Link to heading
So, based on the key differences outlined in the table above when we should opt for Customer-managed KMS key instead of AWS Managed:
- if you want to have more granular control and limit the access to certain services and their data which you want to encrypt (as by default AWS-Managed keys are granting access to everyone within the account who has the neccesary IAM permissions to access KMS)
- if you want to grant access to encrypted service or its data from another service or AWS account (as with AWS managed keys you don’t have access to the KMS key resource policy)
In practice Link to heading
A common use case from the day-to-day practice is to have an S3 bucket in one AWS account to which you want to grant access from another AWS account or to another service within your account. If you need to comply with a security standard or you just want to listen to Werner Vogels and “encrypt everything” your only option would be to create a customer-managed AWS KMS key with which you can encrypt the whole S3 bucket or just the objects in it.