AWS KMS MASTERCLAS - Secure AWS services using AWS KMS
![AWS KMS MASTERCLAS - Secure AWS services using AWS KMS](/content/images/size/w2000/2024/12/kb-ima--6-.png)
In a world where data breaches and unauthorized access are just a news headline away, encryption isn't optional—it's a must-have. But here's the thing: encryption is only as good as the keys securing it. Imagine locking your most valuable belongings in a high-tech safe, but then leaving the key under the doormat—it defeats the purpose, right? That's where AWS Key Management Service (KMS) comes in.
AWS KMS gives you a powerful, easy way to create, manage, and control your encryption keys. Whether you need to lock down an EBS volume, encrypt sensitive files in S3, or set up strong access controls, AWS KMS has your back. Plus, it integrates smoothly with many AWS services, making it an essential part of your cloud security toolkit.
In this post, we'll dive deep into AWS KMS, starting with envelope encryption—a concept that takes key protection to the next level. We'll also cover the different types of KMS keys, how access controls work, and how to use encryption contexts effectively. By the end, you'll have a solid grasp of how AWS KMS can help you protect your data and simplify your security strategy. Ready to get started? Let's jump in!
What is AWS KMS?
As the name suggests, AWS Key Management Service (KMS) is an encryption and key management solution specifically designed for the AWS cloud. It allows organizations to create and manage the keys needed to protect their data across AWS services and applications.
AWS KMS employs hardware security modules (HSMs) to protect and validate all cryptographic keys. These HSMs comply with the FIPS 140-2 Cryptographic Module Validation Program (CMVP), a recognized standard for cryptographic modules.
How Does AWS KMS Work?
How AWS KMS Encryption Works (With EBS Volume Example)
Let’s say you are creating an EBS volume and you want to enable encryption. Here’s what happens:
- KMS Key Stays in KMS:
You specify a KMS key for the EBS volume. This key is securely stored in AWS KMS and never leaves the service. - Generate a Data Key:
When you enable encryption, KMS creates a data key using the KMS key. This data key comes in two forms:- Plain Data Key: Used to encrypt the EBS volume.
- Encrypted Data Key: Stored securely for future decryption.
- Encrypt the EBS Volume:
The plain data key is used to encrypt the data in the EBS volume. Once encryption is done, the plain data key is immediately deleted for security. - Store the Encrypted Data Key:
The encrypted data key is stored alongside the encrypted EBS volume. This ensures that later, when you want to access the volume, the encrypted data key can be used to decrypt it.
![](https://www.kubeblogs.com/content/images/2024/12/image.png)
How AWS KMS Decryption Works (With EBS Volume Example)
Let’s say you want to read or access the data stored in your encrypted EBS volume. Here’s what happens:
- Retrieve the Encrypted Data Key:
The encrypted data key stored with the volume is retrieved. - Send to KMS for Decryption:
The encrypted data key is sent to AWS KMS, where it is decrypted using the KMS key.- AWS KMS returns the plain data key.
- Decrypt the EBS Volume:
The plain data key is then used to decrypt the EBS volume. Once the volume is decrypted, you can read and access the data. - Plain Data Key is Deleted:
After the decryption process, the plain data key is immediately deleted to keep everything secure.
![](https://www.kubeblogs.com/content/images/2024/12/image-1.png)
How AWS KMS Encryption Works (S3 Bucket Example)
![](https://www.kubeblogs.com/content/images/2025/01/Screenshot-2025-01-02-at-8.50.20-AM.png)
Encryption Process
The user uploads an object to S3 with SSE-KMS encryption and can optionally specify a CMK. S3 requests a Data Encryption Key (DEK) from AWS KMS, which provides a Plaintext Key for encryption and a Ciphertext Key encrypted with the CMK. S3 encrypts the object using AES-256 with the Plaintext Key and immediately discards it after encryption. The Ciphertext Key and CMK ID are stored in the object’s metadata, and the encrypted object is saved in the S3 bucket.
Decryption Process
When downloading the object, S3 retrieves the Ciphertext Key from metadata and sends it to AWS KMS for decryption. AWS KMS returns the Plaintext Key, which is temporarily used to decrypt the content. The decrypted object is sent to the user, and the Plaintext Key is discarded.
Why is This Secure?
- KMS Key Stays Safe: The KMS key never leaves AWS KMS. It’s only used inside the service to generate or decrypt data keys.
- Data Key is Temporary: The plain data key exists only for the duration of encryption or decryption. It’s deleted as soon as the process is done.
- End-to-End Protection: Whether it’s an EBS volume, S3 bucket, or RDS database, AWS handles all the encryption and decryption securely.
AWS KMS Key Types.
AWS KMS Key Types Managed vs. Customer-Managed Keys
1. AWS-Managed Keys
These are encryption keys that AWS creates, owns, and manages on your behalf.
Key Features:
- Automatic Management:
AWS handles the creation, rotation, and deletion of the keys. You don’t need to worry about managing the lifecycle of the key. - Limited Visibility and Control:
You don’t have direct control over these keys. They are used by AWS services like S3, EBS, and RDS for encryption when you opt for default encryption. - No Additional Cost:
AWS-managed keys are included in the encryption services for free (except for API calls to encrypt/decrypt data). - Limited Use Cases:
AWS-managed keys can only be used for encryption within the specific AWS service that created them. You cannot use these keys directly in your application code or for cross-service encryption.
When to Use AWS-Managed Keys:
- You need quick and simple encryption for services like S3, EBS, or RDS.
- You don’t require detailed control over the key lifecycle or permissions.
2. Customer-Managed Keys (CMKs)
These are keys that you create, own, and manage in AWS KMS.
Key Features:
- Full Control:
You control the key’s lifecycle, including:- Creation
- Rotation (optional, automated yearly rotation is available)
- Disabling or deleting keys
- Policy configuration for who can use the key and under what circumstances.
- Customizable Permissions:
You can define fine-grained IAM policies and KMS key policies to control which users, roles, or applications can use the key for encryption or decryption. - Cross-Service and Application Use:
CMKs can be used across multiple AWS services or even in your own application code via AWS SDKs. - Audit Logs:
CMKs are fully integrated with AWS CloudTrail, giving you a detailed audit log of all key usage. - Cost:
- CMKs incur a monthly fee (currently $1 per key per month).
- Additional charges apply for API calls (e.g.,
Encrypt
,Decrypt
).
When to Use Customer-Managed Keys:
- You need more control over encryption and key usage policies.
- You want to define custom permissions for specific IAM users or roles.
- You need keys that can be shared across services or used in custom applications.
- You want detailed tracking of key usage for compliance purposes.
Quick Difference Between AWS-Managed Keys and Customer-Managed Keys
Feature | AWS-Managed Keys | Customer-Managed Keys (CMKs) |
---|---|---|
Control | Fully managed by AWS. No control over key policies. | Fully managed by the customer. Customizable policies. |
Key Creation | Automatically created by AWS for specific services. | Created by the customer based on application needs. |
Key Rotation | Automatic annual rotation, managed by AWS. | Optional rotation; must be enabled by the customer. |
Cost | No monthly charge; API usage costs apply. | $1 per key per month + API usage costs. |
Audit Logging | Limited logging. | Fully logged in AWS CloudTrail for auditing. |
Usage Scope | Limited to specific AWS services like S3, EBS, RDS. | Usable across services and custom applications. |
3. AWS-Owned Keys
Hey, there’s another AWS-owned key, which is used exclusively by AWS for internal operations. If you want, you can think of it as a key that AWS uses behind the scenes to secure its system-level tasks, like protecting service metadata or encrypting inter-service communication.
For your knowledge, you don’t get to manage, view, or control these keys—they are entirely maintained by AWS. These keys aren’t visible in CloudTrail or accessible through any AWS service APIs. They work in the background, and AWS services are secure without requiring any customer involvement.
Practical Example: Using AWS KMS with an S3 Bucket
Step 1: Create a Customer-Managed Key (CMK)
- Go to the AWS KMS service in the console.
- Click Create Key → Select Symmetric Key → Click Next.
- Provide an alias (e.g.,
kubenine
) and optional description → Click Next.
![](https://www.kubeblogs.com/content/images/2024/12/image-2.png)
- Assign a key administrator.
![](https://www.kubeblogs.com/content/images/2024/12/image-3.png)
- Assign key usage permissions.
![](https://www.kubeblogs.com/content/images/2024/12/image-4.png)
6.Review the configuration → Click Create Key.
- When creating the Customer-Managed Key (CMK), AWS KMS automatically generates a Key Policy. Below is an example key policy that includes two statements, each serving a specific purpose:
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::905418054480:user/dipchand"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::905418054480:user/dipchand"
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
Step 2: Enable Default Encryption on the S3 Bucket
- Open the bucket → Go to the Properties tab.
- Scroll to Default Encryption → Click Edit.
- Select AWS Key Management Service key (SSE-KMS).
- Choose your CMK (
Kubenine
) → Save changes.
![](https://www.kubeblogs.com/content/images/2024/12/image-5.png)
Step3: Fetch the Object Using AWS CLI
Use the following command to fetch the file from the S3 bucket:
aws s3 cp s3://terraform-state-cloudflare/tfstate/cloudflare_dns/terraform.tfstate ./terraform.tfstate
This is the output I got :
![](https://www.kubeblogs.com/content/images/2024/12/image-6.png)
When you run the aws s3 cp
command to fetch the terraform.tfstate
file, the process works because your user has the required decrypt permissions (kms:Decrypt
). Here's what happens behind the scenes:
- S3 retrieves the encrypted data key associated with the file. This key was created during the upload and stored with the object in the bucket.
- S3 sends the encrypted data key to AWS KMS, where it is decrypted using the Customer-Managed Key (CMK) you attached to the bucket.
- Once the plain data key is returned from AWS KMS, S3 uses it to decrypt the file and provide the decrypted content to your terminal.
- This entire process is handled automatically by AWS, and because your user has the correct permissions, the file is fetched and decrypted successfully, allowing you to view its contents.
Using AWS-Managed Keys with S3 Bucket Encryption
We can't create an AWS-Managed Key because it's created and managed by AWS itself. However, we can use it for services like S3 to enable encryption quickly and securely. Let’s take an example and see how it works.
Enable Default Encryption:
- Open the bucket → Go to Properties → Scroll to Default Encryption → Click Edit.
- Select AWS Key Management Service key (SSE-KMS) → Choose AWS-Managed Key.
- Save the changes.
![](https://www.kubeblogs.com/content/images/2024/12/image-7.png)
- As you can see in the image, AWS automatically creates an AWS-Managed KMS Key named
aws/s3
when enabling server-side encryption with AWS-Managed Keys. This key is entirely managed by AWS, All operations such as creation, rotation, and deletion are handled by AWS.
While this setup is simple and easy to use, it has a key limitation: you have no control over the key's lifecycle or policies. This can be a drawback if your use case requires granular permissions, user-specific access, or compliance with strict security requirements. However, for general-purpose encryption, AWS-Managed Keys provide a quick solution.
AWS KMS cost:
- Customer-Managed KMS Keys
- There is a monthly charge of $1 per key (pro-rated for partial months).
- Usage Charges
- Both AWS-managed and customer-managed keys incur usage charges for operations like
GenerateDataKey
,Encrypt
, andDecrypt
. - The cost is $0.03 per 10,000 requests.
- Both AWS-managed and customer-managed keys incur usage charges for operations like
- AWS-Owned Keys
- No additional charges for AWS-owned keys, but they are limited to specific internal AWS services.
- Cross-Account Key Usage
- When a KMS key is used from a different AWS account, the account making the API request is charged for the key usage.
Conclusion:
There’s so much more to explore about AWS KMS, but for this blog, we’ve focused on the core topics. We covered how AWS KMS works with practical examples and highlighted the problems it solves. From understanding encryption and decryption to setting up AWS-Managed Keys and Customer-Managed Keys, you’ve seen how KMS helps secure your data and services.
AWS KMS is a great choice for protecting your cloud resources. And if you’re looking to take your security a step further, feel free to reach out to us at KubeNine. Our expertise in Cloud, DevOps, and infrastructure management means you can concentrate on building your product while we handle the complexities of managing it.
If you found this blog helpful, please share it with your friends or colleagues. For any questions or assistance, don’t hesitate to contact us at KubeNine. We’re here to help you every step of the way!