AWS Key Management Service (KMS) is a managed service that makes it easy for you to create and control the encryption keys used to encrypt your data. It integrates with most AWS services, simplifying data protection.
Let’s see KMS in action. Imagine you have sensitive data in an S3 bucket. You want to ensure that even if someone gains unauthorized access to the bucket, they can’t read the data without the correct decryption key.
Here’s a simple S3 bucket policy that denies access to any object unless it’s encrypted with a specific KMS key:
{
"Version": "2012-02-01",
"Id": "PutObjectPolicy",
"Statement": [
{
"Sid": "DenyIncorrectEncryptionHeader",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-encrypted-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:111122223333:key/your-kms-key-id"
}
}
},
{
"Sid": "DenyUnencryptedObject",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-encrypted-bucket/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption": "true"
}
}
}
]
}
When you upload an object to my-encrypted-bucket, you’d specify the KMS key to use for encryption:
aws s3 cp my-local-file.txt s3://my-encrypted-bucket/my-local-file.txt --sse aws:kms --sse-kms-key-id arn:aws:kms:us-east-1:111122223333:key/your-kms-key-id
If you try to upload without specifying the KMS key, or with a different key, the DenyIncorrectEncryptionHeader or DenyUnencryptedObject statements in the bucket policy will prevent the upload. The data is then encrypted by KMS before it’s written to S3. When you later retrieve the object, S3 automatically uses the KMS key to decrypt it for you, provided your IAM user or role has the necessary permissions.
KMS allows you to control access to your encryption keys using IAM policies. You can grant permissions to specific IAM users and roles to use a key for encryption and decryption, or even to manage the key itself (e.g., change its description, schedule it for deletion). This granular control is crucial for maintaining data security and compliance.
The core problem KMS solves is the secure generation, storage, and management of cryptographic keys. Before KMS, managing encryption keys was a significant operational burden. You’d have to generate keys, securely store them (often in hardware security modules or HSMs), manage their lifecycle (rotation, revocation), and integrate them into your applications for encryption and decryption. KMS abstracts all of this complexity, offering a highly available, durable, and secure service.
Internally, KMS uses FIPS 140-2 validated hardware security modules (HSMs) to protect your keys. When you create a key, KMS generates it within these HSMs. When you request an encryption or decryption operation, KMS performs that operation within the HSMs, ensuring your key material never leaves the secure hardware boundary.
You can create two main types of customer managed keys: Symmetric and Asymmetric. Symmetric keys use the same key for encryption and decryption, which is generally more performant and suitable for most use cases like encrypting data at rest in services like S3, EBS, or RDS. Asymmetric keys have a public and private key pair; the public key is used for encryption and the private key for decryption. These are useful for scenarios like encrypting data to be decrypted by a different party or for digital signatures.
When you create a KMS key, you specify its key policy. This policy is attached to the KMS key and defines who can perform what actions on that key. It’s separate from IAM policies, which define what actions an IAM principal can perform on AWS resources. A key policy specifies principals (AWS accounts, IAM users, IAM roles) and their allowed or denied actions (e.g., kms:Encrypt, kms:Decrypt, kms:GenerateDataKey). For a KMS operation to succeed, both the IAM policy of the caller and the key policy of the KMS key must allow the action.
A common misconception is that KMS encrypts your data directly. In reality, KMS often generates a unique data key for each encryption operation. It then encrypts your data using this data key (using a symmetric algorithm like AES-256) and then encrypts the data key itself using your KMS customer master key (CMK). The encrypted data key is then stored alongside your encrypted data. When you need to decrypt, KMS uses your CMK to decrypt the data key, and then uses that data key to decrypt your actual data. This approach is highly scalable and efficient for encrypting large amounts of data.
The next step after mastering KMS key management is exploring how to use KMS with AWS CloudHSM for even greater control over your keys.