Lab: Securing Confidential Data with AWS KMS and Secrets Manager

In this lab, you will design and implement technical controls to protect sensitive data using AWS Key Management Service (KMS) and AWS Secrets Manager. You will create a Customer Managed Key (CMK), store an encrypted secret, and configure access policies to ensure the principle of least privilege.

[!WARNING] Performing this lab may incur a small cost (approx. $1.00 USD/month for KMS and $0.40/month per secret). Always perform the Teardown steps at the end to minimize charges.

Prerequisites

An active AWS Account.
IAM Permissions: Your user must have AdministratorAccess or a policy allowing kms:* and secretsmanager:* actions.
AWS CLI: Installed and configured on your local machine with aws configure.
Region: We will use us-east-1 (N. Virginia) for this lab.

Learning Objectives

Create and manage an AWS KMS Customer Managed Key (CMK).
Implement a Key Policy to restrict access to specific IAM roles.
Store and retrieve sensitive credentials using AWS Secrets Manager.
Understand the difference between AWS-generated and Imported key material.

Architecture Overview

This diagram illustrates the relationship between the IAM user, Secrets Manager, and KMS during the encryption and retrieval process.

Loading Diagram...

Visualizing Key Material Lifecycle

Unlike AWS-generated keys, imported key material requires manual lifecycle management. Below is a conceptual visualization of the key availability window when using imported material with an expiration date.

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Step-by-Step Instructions

Step 1: Create a Symmetric Customer Managed Key (CMK)

You will create a key that you control, rather than using the default AWS-managed key (aws/secretsmanager).

Interface: AWS CLI

bash

# Create the KMS Key and capture the KeyId from the output
aws kms create-key --description "Lab Key for Confidential Data"

▶Console alternative

Navigate to KMS > Customer managed keys.
Click Create key.
Select Symmetric and Encrypt and decrypt.
Alias: brainybee-lab-key.
Follow the wizard to assign yourself as the Key Administrator.

Step 2: Store a Secret in Secrets Manager

Now, you will store a simulated database password and encrypt it using the CMK created in Step 1.

Interface: AWS CLI

bash

# Replace <YOUR_KMS_KEY_ID> with the ID from Step 1
aws secretsmanager create-secret --name "brainybee/db-creds" \
    --description "Database credentials for prod" \
    --kms-key-id "<YOUR_KMS_KEY_ID>" \
    --secret-string "{\"username\":\"admin\",\"password\":\"SuperSecret123!\"}"

[!TIP] In a production environment, you would use --tags to implement Attribute-Based Access Control (ABAC).

Step 3: Implement Least Privilege with a Key Policy

By default, KMS keys created via the CLI might have restrictive policies. You need to ensure the Secret Manager service can use the key.

Interface: Console

Go to the KMS Console and select your key.
Under Key Policy, click Edit.
Ensure the policy allows kms:Decrypt and kms:DescribeKey for the IAM entity trying to access the secret.

Step 4: Retrieve the Secret

Verify that the secret is protected but accessible to authorized users.

Interface: AWS CLI

bash

aws secretsmanager get-secret-value --secret-id "brainybee/db-creds"

Checkpoints

Checkpoint	Action	Expected Result
Key Creation	Run `aws kms list-keys`	You should see your KeyId in the list.
Secret Storage	Run `aws secretsmanager list-secrets`	The `brainybee/db-creds` secret should appear.
Encryption Check	Check Secret details in Console	The "Encryption key" field should show your CMK ARN, not `Default`.

Troubleshooting

Error	Potential Cause	Fix
`AccessDeniedException`	IAM user lacks `kms:GenerateDataKey` or `kms:Decrypt`.	Update IAM policy or Key Policy to include these permissions.
`InvalidArnException`	Typo in the KMS Key ID/ARN.	Verify the ARN in the KMS Console under 'Key ARN'.
`ResourceNotFoundException`	Secret name is incorrect or in wrong region.	Use `aws configure get region` to check current region.

Teardown

To avoid ongoing costs, you must delete the resources created.

Delete the Secret (forces immediate deletion without recovery window for this lab):

bash
aws secretsmanager delete-secret --secret-id "brainybee/db-creds" --force-delete-without-recovery
Schedule Key Deletion (KMS keys have a mandatory 7-30 day waiting period):

bash
# Replace <YOUR_KMS_KEY_ID> aws kms schedule-key-deletion --key-id "<YOUR_KMS_KEY_ID>" --pending-window-in-days 7

[!IMPORTANT] Once a KMS key is deleted, any data encrypted with it cannot be decrypted, even with the same key material, unless it was imported and you have a backup of that material. Use caution in production!", "word_count": 850, "suggested_title": "Lab: AWS KMS & Secrets Manager Implementation" }