More Info:
Ensure that your Amazon Secrets Manager secrets (i.e. database credentials, API keys, OAuth tokens, etc) are encrypted with Amazon KMS Customer Master Keys (CMKs) instead of default encryption keys that Secrets Manager service creates for you, in order to have a more granular control over secret data encryption and decryption process, and meet compliance requirements.Risk Level
HighAddress
SecurityCompliance Standards
GDPR, NIST, NISTCSF, PCIDSSRemediation
How to ensure secrets manager secrets are encrypted with CMKsUsing AWS Console
- Log in to the AWS Management Console using your AWS account credentials.
- Navigate to the AWS Secrets Manager service by selecting “Secrets Manager” from the services menu.
- In the Secrets Manager dashboard, click on “Secrets” in the left navigation pane. (In the Cloudanix Console, navigate to “Misconfig” page and look for Affected Assets for “Secret Manager Secrets Should Be Encrypted With CMKs” Policy.)
- Identify the secrets that are not encrypted with CMKs.
- Take note of the specific secret identifier(s) that need remediation.
- Select the checkbox next to the secret(s) you want to remediate.
- Above the list of secrets, click on the “Edit rotation” button.
- In the “Configure secret rotation” page, click on the “Edit secret” button.
- In the “Secret details” section, scroll down to the “Encryption” configuration.
- Select the option to “Use AWS Key Management Service (KMS) key” for encryption.
- Choose an appropriate CMK from the dropdown menu or create a new CMK if necessary.
- Click on the “Save” button to apply the encryption configuration.
- In the “Configure secret rotation” page, click on the “Next” button.
- Review and modify the rotation settings as needed and click on the “Next” button.
- Review the summary of the rotation configuration and click on the “Finish” button.
- Monitor the rotation process to ensure it is successfully completed for the remediated secrets.
- Repeat these steps for each secret that is not encrypted with CMKs until all secrets have been remediated.
Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
Below are the step‑by‑step remediation instructions using the AWS Management Console so your AWS Secrets Manager secrets are encrypted with customer‑managed KMS keys (CMKs) instead of AWS‑managed keys.
Repeat step 2 for all Secrets Manager secrets flagged by your scanner until each shows your customer‑managed KMS key as the encryption key.
1. Create (or Identify) a Customer‑Managed KMS Key
If you don’t already have a CMK for Secrets Manager:-
Sign in to the AWS Management Console and go to AWS KMS
- Services → Key Management Service (KMS)
- In the left pane, choose Customer managed keys.
- Click Create key.
-
Under Key type, choose Symmetric and Encryption and decryption.
(This is standard for Secrets Manager.) - Click Next.
-
Add an alias (e.g.,
alias/secrets-manager-key). - Configure Key administrators (IAM users/roles that can manage the key), then Next.
-
Configure Key usage permissions:
- Add IAM roles/users used by your applications or services that access the secrets.
- Optionally add the Secrets Manager service principal if using resource policies (advanced).
- Finish with Create key.
alias/secrets-manager-key).2. Update Each Secret to Use the CMK
For each secret currently using the default AWS‑managed key, change it to your CMK:-
Go to AWS Secrets Manager in the console.
- Services → Secrets Manager
- In Secrets, click the secret name you want to remediate.
- On the secret’s details page, choose the Edit button.
- Scroll down to the Encryption key or KMS key section.
-
From the dropdown, select your customer‑managed CMK
- e.g.,
alias/secrets-manager-key.
- e.g.,
- Review other settings (no change needed for rotation unless desired).
- Click Save.
3. Verify Permissions and Access
-
Still on the secret details page, use the Secret value → Retrieve secret value button.
- If retrieval succeeds for your application role/user, KMS permissions are correct.
-
If you get an access error:
- Go back to KMS → Customer managed keys.
- Select your key → Key policy.
- Ensure the application IAM roles/users are allowed
kms:Decryptandkms:GenerateDataKeyon this key.
4. (Optional) Enforce Use of CMKs Going Forward
To avoid regressions:- In your infrastructure as code (CloudFormation/Terraform), always specify the
KmsKeyIdfor secrets. - In organizational policies (e.g., AWS Config rules, Security Hub controls), flag secrets using AWS‑managed keys instead of CMKs.
Repeat step 2 for all Secrets Manager secrets flagged by your scanner until each shows your customer‑managed KMS key as the encryption key.
Using CLI
Using CLI
Below are minimal, CLI-focused steps to ensure AWS Secrets Manager secrets are encrypted with a customer-managed KMS key (CMK), not the AWS-managed default key.
Any secret with
Capture the Optionally, add an alias:You can use either the
Or with a direct KeyId:
Each remediated secret should now show your CMK ARN (or alias ARN) instead of
1. Identify Secrets Not Using a CMK
List all secrets and see which KMS key they use:null or an AWS-managed key (like aws/secretsmanager) should be remediated.2. (Optional) Create a Customer-Managed KMS Key (CMK)
If you don’t already have a CMK:KeyId from the output, e.g.:KeyId, full ARN, or alias ARN (e.g. arn:aws:kms:region:account-id:alias/secretsmanager-cmk) in the next step.3. Update Each Secret to Use the CMK
For a single secret:4. Bulk Remediation (All Secrets Without CMK)
Example Bash loop to switch all secrets with noKmsKeyId to a specific CMK alias:5. Verify the Change
Re-check the KMS key for your secrets:null or an AWS-managed key.Using Python
Using Python
Below is a concise, step‑by‑step way to ensure AWS Secrets Manager secrets are encrypted with a customer‑managed KMS key (CMK) using Python (boto3).
Record
Notes:
(Also grant your IAM roles/users as needed.)
If you tell me how you currently organize your secrets (per app, per environment, etc.), I can adapt the bulk‑remediation script to your naming scheme or tagging strategy.
1. Prerequisites
- Python 3.x
boto3installed:- IAM permissions:
kms:CreateKey,kms:DescribeKey,kms:ListKeys,kms:EnableKeyRotation(if creating/using CMK)secretsmanager:DescribeSecret,secretsmanager:UpdateSecret,secretsmanager:ListSecrets
2. Create (or Identify) a Customer-Managed KMS Key
If you already have a CMK you want to use, note its KeyId or ARN and skip to step 3.2.1 Create a CMK with Python
cmk_id or the full ARN (you can use either as KmsKeyId).3. Check Existing Secrets for Default AWS-Managed KMS Key
- If
KmsKeyIdisNone, the secret is using the default AWS-managed key. - If it’s set but not your CMK, you’ll want to change it.
4. Re-encrypt an Existing Secret with Your CMK
This changes the KMS key used going forward for all secret versions.update_secretwill cause future encrypt/decrypt operations to use this CMK.- Old ciphertext blobs are effectively re‑encrypted when accessed; you do not need to rewrite the secret value.
5. Create a New Secret Encrypted with CMK
6. Bulk Remediation: Migrate All Secrets to a CMK
Example: update every secret currently using the default AWS‑managed key.7. KMS Key Policy Considerations
Ensure your CMK key policy allows Secrets Manager and principals that use the secret to use the key:Minimal example snippet (KMS key policy statement):If you tell me how you currently organize your secrets (per app, per environment, etc.), I can adapt the bulk‑remediation script to your naming scheme or tagging strategy.
Using Terraform
Using Terraform
kms_key_id on an existing aws_secretsmanager_secret forces replacement of the secret resource in Terraform, which may cause a brief outage if consumers are not updated to the new ARN; plan carefully before applying.Verification: terraform plan should show creation of aws_kms_key.secrets_cmk (if new) and either creation of a new aws_secretsmanager_secret.example or an update that replaces it, with kms_key_id set to the CMK ARN instead of the default AWS-managed key.
