Skip to main content

Triage and Remediation

Remediation

Using Console

In AWS, Secrets Manager secrets are always encrypted; remediation usually means ensuring they use a customer-managed AWS KMS key instead of the default AWS-managed key.Below are step‑by‑step instructions using the AWS Console.

1. Create (or identify) a customer-managed KMS key

  1. Sign in to the AWS Management Console.
  2. Go to AWS Key Management Service (KMS):
    • In the search bar, type KMS and select Key Management Service.
  3. In the left navigation pane, choose Customer managed keys.
  4. Click Create key.
  5. Key type: select Symmetric and Encrypt and decrypt.
  6. Click Next.
  7. Add an Alias (e.g., alias/secretsmanager-default).
  8. Configure Key administrators and Key users:
    • Ensure the IAM roles/users and the Secrets Manager service role (if you use one) that will access the secrets are added as Key users.
  9. Complete the wizard by clicking Finish.
Note the Key ID or Alias; you’ll need it when assigning to secrets.

2. Update existing secrets to use the KMS CMK

You must do this per secret.
  1. Go to AWS Secrets Manager in the console.
  2. On the Secrets page, click the secret you want to remediate.
  3. On the secret’s details page, click Edit.
  4. In the Encryption key section:
    • Change from the default (e.g., aws/secretsmanager) to your customer-managed KMS key (e.g., alias/secretsmanager-default).
  5. Scroll down and click Save.
Repeat for all existing secrets that should use the customer-managed KMS key.

3. Ensure new secrets are encrypted with the CMK by default (process-wise)

There is no global “default CMK” switch for Secrets Manager; you enforce it by process or IaC. Using the console:
  1. When you create a new secret in Secrets Manager:
    • On the Store a new secret page, in the Encryption key dropdown, select your customer-managed KMS key.
  2. Complete the secret creation as usual.
To make this “by default” in practice:
  • Update internal runbooks so all admins select the CMK.
  • If you use CloudFormation/Terraform, set KmsKeyId to your CMK in those templates so all programmatically created secrets use that key automatically.

This remediation ensures all Secrets Manager secrets are encrypted with a customer-managed AWS KMS key, satisfying controls that require non-default or customer-managed encryption.
In AWS Secrets Manager, all secrets are always encrypted, but by default they use the AWS managed key aws/secretsmanager. To meet a “Secret Manager should be encrypted by default (with KMS CMK)” requirement, you typically must:
  1. Create or identify a customer-managed KMS key.
  2. Ensure all new secrets are created with that key.
  3. Re‑encrypt existing secrets to use that key.
Below are the AWS CLI steps.

1. Create a customer-managed KMS key (if you don’t already have one)

Note the "KeyId" from the output (for example: arn:aws:kms:us-east-1:111122223333:key/abcd-...).Optionally give it an alias:

2. Use the CMK when creating new secrets

When creating a secret, specify --kms-key-id (either the key ARN or alias):
This ensures the secret is encrypted by your CMK rather than aws/secretsmanager.If you’re using automation (CloudFormation, Terraform, pipelines, etc.), update those definitions to always pass the CMK.

3. Re-encrypt existing secrets with the CMK

List your secrets:
For each secret that is not using your CMK, update it:
You can script it, for example (bash):
(Requires jq.)

4. Ensure IAM permissions and key policy allow usage

Make sure principals that manage/use secrets can use the CMK:Example key policy snippet (attach/update via put-key-policy or console):
And allow your admins/automation roles to use the CMK as well.
These steps ensure Secrets Manager secrets are encrypted by a customer-managed KMS key by default and remediate the “Secret Manager should be encrypted by default (AWS KMS)” finding.
In AWS Secrets Manager, every secret is encrypted with KMS, but many checks require that you use a customer-managed KMS key (CMK) instead of the default aws/secretsmanager key.
Remediation with Python (boto3) is:
  1. Prerequisites
    • Python 3.x
    • boto3 installed:
    • IAM permissions:
      • secretsmanager:ListSecrets, secretsmanager:DescribeSecret, secretsmanager:UpdateSecret
      • kms:DescribeKey, kms:CreateKey, kms:ListAliases

Step 1: Choose or create a KMS key

Either use an existing CMK or create one. Example to create a CMK and alias via Python:
You can then reference the key as either key_id or arn or the alias alias/secretsmanager-default-kms.

Step 2: Find secrets not using your CMK

This script:
  • Lists all secrets
  • Checks if their KmsKeyId is set and whether it matches your target CMK
  • Prints the ones that need remediation

Step 3: Re-encrypt each secret with the desired CMK

Use UpdateSecret with KmsKeyId. This causes Secrets Manager to re-encrypt the secret value with the new KMS key.
This remediates existing secrets by ensuring they are encrypted with your customer-managed KMS key.

Step 4: Create new secrets always using your CMK (default behavior in code)

When creating new secrets in Python, always specify KmsKeyId:
To make this “default” in your environment:
  • Ensure all IaC/templates and application code that call Secrets Manager always pass KmsKeyId=<your CMK>.
  • Optionally enforce via code review, CI checks, or policy tools (e.g., CloudFormation Guard, Terraform rules).
Changing kms_key_id on an existing aws_secretsmanager_secret is an in-place update and should not force replacement of the secret or cause downtime.Verification: terraform plan should show an in-place update (~) on the existing aws_secretsmanager_secret.SECRET_RESOURCE_NAME resource, with kms_key_id changing from null or the previous key ARN to the ARN of aws_kms_key.SECRETS_KMS_KEY.