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:

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.