Kms secrets manager in use remediation

Using Console

Below are step‑by‑step console instructions to ensure you’re actually using AWS Secrets Manager (with KMS) rather than just KMS alone for secrets.

1. Choose or Create a KMS Key for Secrets Manager

Sign in to AWS Management Console.
Go to IAM > left menu Encryption keys (KMS)
or directly open AWS Key Management Service (KMS).
In the left pane, select Customer managed keys.
Either:
- Use an existing key: Note the Key ID or Alias you want Secrets Manager to use,
  or
- Create a new KMS key:
  1. Click Create key.
  2. Key type: Symmetric and Encrypt and decrypt.
  3. Give it an Alias (e.g. alias/secrets-manager-key).
  4. Configure key administrators and key usage permissions.
  5. Finish. Note the alias or key ID.

This key will encrypt the secrets stored in Secrets Manager.

2. Create a Secret in AWS Secrets Manager

In the console, go to AWS Secrets Manager.
Click Store a new secret.
Under Secret type, choose the appropriate option:
- Other type of secret for arbitrary key/value pairs, or
- A specific type like Credentials for RDS database, etc.
In Key/value pairs, add your secret values (for example username, password, apiKey, etc.).
Under Encryption key, choose:
- aws/secretsmanager (AWS-managed)
  or
- Your customer-managed KMS key (e.g. alias/secrets-manager-key).
Click Next.
Enter a Secret name (e.g. prod/db/credentials).
(Optional) Add a Description and Tags.
Click Next to pass rotation for now, or configure it (see step 3).
Review and click Store.

Your secret is now stored and encrypted with KMS, satisfying “Secrets Manager in use.”

3. (Recommended) Enable Automatic Rotation

In Secrets Manager, click the secret you just created.
Go to the Rotation tab.
Click Edit rotation.
Check Enable automatic rotation.
Choose Create a new Lambda function or Use an existing Lambda function to rotate the secret.
Set the Rotation interval (e.g. every 30 days).
Save changes.

4. Update Applications to Use Secrets Manager Instead of KMS/Plaintext

Your misconfiguration is typically that apps are:

Hardcoding secrets, or
Storing them encrypted with KMS directly (e.g. via Encrypt/Decrypt API) but not using Secrets Manager.

Update each application to fetch secrets from Secrets Manager:

A. Grant the Application IAM Permissions

Assign an IAM role or user policy like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:prod/db/credentials-*"
    }
  ]
}

If using a customer-managed KMS key, ensure the role is also allowed to use it in the KMS key policy.

B. Update Code to Call Secrets Manager

Example patterns:

AWS SDK (pseudo-code):

import boto3, json

client = boto3.client('secretsmanager', region_name='us-east-1')
response = client.get_secret_value(SecretId='prod/db/credentials')
secret = json.loads(response['SecretString'])
username = secret['username']
password = secret['password']

Do this instead of:

Reading a plaintext config file, or
Calling KMS Decrypt directly on some encrypted blob.

Test the app, deploy changes, and confirm it runs using Secrets Manager.

5. Decommission Old Secret Storage

Once all consumers have been migrated to Secrets Manager:

Remove old secrets from:
- Plaintext config files / environment variables.
- SSM Parameter Store (if previously used for secrets in plaintext).
- Custom KMS-encrypted blobs in S3, etc.
If you had separate KMS keys only used for that old pattern:
- Confirm they are no longer needed.
- Schedule key deletion in KMS (optional, and only after verifying everything works).

6. Verify Remediation

In Secrets Manager, verify:
- All required secrets exist.
- They are encrypted with a KMS key.
- Rotation is configured (if applicable).
In CloudTrail, you should see GetSecretValue calls from your application role.
Confirm your security tool / compliance rule for “Secrets Manager should be in use” is now passing.

If you share the exact rule (e.g., from Security Hub, Config, or a CSPM tool), I can tailor the minimum required steps specifically for that control.

Using CLI

Below are CLI-focused steps to get secrets into AWS Secrets Manager and away from direct KMS usage.Assumptions:

You currently have some secret (password/API key/etc.) stored outside Secrets Manager (maybe in plaintext, SSM Parameter, environment variables, or encrypted manually with KMS).
You want to store it in AWS Secrets Manager and encrypt it with a KMS key.

1. Choose or create a KMS key for Secrets Manager

If you already have a suitable customer managed key (CMK), note its key-id/ARN and skip creation.Create a new KMS key:

aws kms create-key \
  --description "KMS key for Secrets Manager secrets" \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS

Capture the KeyId or Arn from the output, e.g.:

KMS_KEY_ID="arn:aws:kms:us-east-1:111122223333:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Optionally give it an alias:

aws kms create-alias \
  --alias-name alias/secrets-manager-key \
  --target-key-id "$KMS_KEY_ID"

2. Create the secret in Secrets Manager

If you already have the secret value available in plaintext locally (e.g. in a shell variable):

SECRET_NAME="my-app/db-password"
SECRET_VALUE="SuperSecretPassword123!"
REGION="us-east-1"

aws secretsmanager create-secret \
  --name "$SECRET_NAME" \
  --description "DB password for my-app" \
  --kms-key-id "$KMS_KEY_ID" \
  --secret-string "$SECRET_VALUE" \
  --region "$REGION"

If the value is in a file:

aws secretsmanager create-secret \
  --name "$SECRET_NAME" \
  --description "DB password for my-app" \
  --kms-key-id "$KMS_KEY_ID" \
  --secret-string file://secret.json \
  --region "$REGION"

secret.json could be:

{
  "username": "dbuser",
  "password": "SuperSecretPassword123!"
}

3. (Optional) Enable automatic rotation for the secret

You need a Lambda function that knows how to rotate this secret. Assume you already created a rotation Lambda with ARN in $ROTATION_LAMBDA_ARN.Enable rotation every 30 days:

ROTATION_DAYS=30
ROTATION_LAMBDA_ARN="arn:aws:lambda:us-east-1:111122223333:function:rotate-myapp-db"

aws secretsmanager rotate-secret \
  --secret-id "$SECRET_NAME" \
  --rotation-lambda-arn "$ROTATION_LAMBDA_ARN" \
  --rotation-rules AutomaticallyAfterDays=$ROTATION_DAYS \
  --region "$REGION"

4. Update application to read from Secrets Manager (CLI test)

Confirm you can read the secret:

aws secretsmanager get-secret-value \
  --secret-id "$SECRET_NAME" \
  --region "$REGION" \
  --query SecretString \
  --output text

Use the returned value in your application (via SDK / environment init script, etc.), instead of directly from KMS or plaintext.

5. Remove old KMS-based / plaintext storage

Once your app is confirmed to be using Secrets Manager:

If you were storing the secret in an SSM parameter:

aws ssm delete-parameter \
  --name "/my-app/db-password" \
  --region "$REGION"

If you stored ciphertext via KMS directly (e.g., in a file / config store), delete or overwrite that configuration securely.
If you had environment variables or config files containing the secret, remove/rotate them.

6. Lock down IAM so secrets must live in Secrets Manager

Example: grant your app role permission to read the secret, not to use KMS directly for secret decryption.Inline policy example (modify as needed):

cat > app-secrets-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadSecret",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/db-password-*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name my-app-role \
  --policy-name MyAppSecretsAccess \
  --policy-document file://app-secrets-policy.json

And optionally restrict general KMS access so applications are not expected to manage sensitive secrets using bare KMS calls.

If you tell me how your secret is currently stored (SSM, env var, KMS-encrypted file, etc.), I can give exact CLI commands tailored to that case.

Using Python

To remediate “Secrets Manager should be in use” for secrets currently stored/managed via KMS, you essentially need to:

Store the secret in AWS Secrets Manager (encrypted with KMS).
Update applications to read from Secrets Manager instead of wherever they’re getting the secret now.
Optionally delete/retire the old KMS-based secret storage.

Below are the steps and example Python (boto3) snippets.

1. Prerequisites

Python 3.x
boto3 installed:
pip install boto3
AWS credentials configured (via environment variables, shared credentials file, or IAM role).
A KMS key you want Secrets Manager to use (can be the AWS-managed default or a customer-managed key).

2. Create a Secret in AWS Secrets Manager (using KMS)

Assume you currently have a secret value (e.g., password or API key) that might be stored in a config file, environment variable, or some other non–Secrets Manager location.

import boto3
import json

secrets_client = boto3.client("secretsmanager", region_name="us-east-1")

secret_name = "my-app/db-password"
secret_value = {
    "username": "db_user",
    "password": "SuperSecurePassword123!"
}

# Optional: specify a customer-managed KMS key
kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/your-kms-key-id"

response = secrets_client.create_secret(
    Name=secret_name,
    Description="Database credentials for my-app",
    SecretString=json.dumps(secret_value),
    KmsKeyId=kms_key_id  # omit to use default aws/secretsmanager key
)

print("Created secret ARN:", response["ARN"])

Remediation impact:

Secret is now stored in Secrets Manager, encrypted with KMS.
Access is controlled via IAM policies and Secrets Manager resource policies.

3. Retrieve the Secret from Secrets Manager in Your App

Replace existing logic (e.g., reading from env vars, files, or direct KMS Decrypt) with Secrets Manager retrieval.

import boto3
import json

secrets_client = boto3.client("secretsmanager", region_name="us-east-1")

secret_name = "my-app/db-password"

def get_db_credentials():
    response = secrets_client.get_secret_value(SecretId=secret_name)

    if "SecretString" in response:
        secret_dict = json.loads(response["SecretString"])
    else:
        # if stored as binary (not common for basic creds)
        import base64
        secret_dict = json.loads(
            base64.b64decode(response["SecretBinary"])
        )

    return secret_dict["username"], secret_dict["password"]

# Example usage
username, password = get_db_credentials()

4. (Optional) Enable Automatic Secret Rotation

If the secret is a database password or similar, use a Lambda rotation function. The basic API call:

rotation_response = secrets_client.rotate_secret(
    SecretId=secret_name,
    RotationLambdaARN="arn:aws:lambda:us-east-1:111122223333:function:my-secret-rotation-fn",
    RotationRules={
        "AutomaticallyAfterDays": 30
    }
)
print("Rotation enabled:", rotation_response)

You must:

Implement the Lambda function to actually change the secret in the target system (DB, API, etc.).
Attach a role to the Lambda allowing it to read/write the secret and update the backend credential.

5. Decommission the Old KMS-Based Storage (If Applicable)

If your prior pattern was something like:

Encrypting secrets manually with KMS and storing ciphertext in files/parameters, or
Storing plaintext secrets in config with occasional KMS use,

then after updating all consumers to use Secrets Manager:

Verify no application still reads the old data.
Remove or redact old secrets (e.g., from SSM Parameter Store, config files, S3, etc.).

Optionally schedule deletion of the KMS key if it was dedicated purely for that legacy pattern and is no longer needed:

kms_client = boto3.client("kms", region_name="us-east-1")
kms_client.schedule_key_deletion(
    KeyId="arn:aws:kms:us-east-1:111122223333:key/your-old-kms-key-id",
    PendingWindowInDays=30
)

6. IAM Permissions (High-level)

Ensure the application role or user has at least:

To read the secret:
- secretsmanager:GetSecretValue
To create/manage the secret (for your provisioning code):
- secretsmanager:CreateSecret
- secretsmanager:PutSecretValue
- secretsmanager:UpdateSecret
- secretsmanager:RotateSecret (if using rotation)

And appropriate KMS permissions for the key in KmsKeyId:

kms:Encrypt
kms:Decrypt
kms:GenerateDataKey
kms:DescribeKey

If you share what your current KMS usage pattern is (e.g., using kms:Decrypt on ciphertext from a file, SSM parameter, etc.), I can give a more exact “before/after” Python example for that specific migration.

Using Terraform

resource "aws_kms_key" "APP_KMS_KEY" {
  description             = "KMS key for encrypting Secrets Manager secrets for APP_NAME"
  deletion_window_in_days = 30
  enable_key_rotation     = true

  tags = {
    Name = "APP_NAME-kms-key"
  }
}

resource "aws_secretsmanager_secret" "APP_SECRET" {
  name        = "APP_NAME/DB_PASSWORD" # replace with your secret name
  description = "Database password for APP_NAME"

  # Use the KMS CMK instead of the default AWS managed key
  kms_key_id = aws_kms_key.APP_KMS_KEY.arn

  tags = {
    Name = "APP_NAME-db-password"
  }
}

resource "aws_secretsmanager_secret_version" "APP_SECRET_VALUE" {
  secret_id     = aws_secretsmanager_secret.APP_SECRET.id
  secret_string = var.APP_DB_PASSWORD # store the secret here (e.g., from a sensitive Terraform variable)
}

variable "APP_DB_PASSWORD" {
  description = "Database password for APP_NAME"
  type        = string
  sensitive   = true
}

This change does not force replacement of the KMS key; it creates a new Secrets Manager secret encrypted with that key (creating the KMS key itself is also non-disruptive unless you switch existing resources to use it).Verification: terraform plan should show 3 to add (aws_kms_key.APP_KMS_KEY, aws_secretsmanager_secret.APP_SECRET, aws_secretsmanager_secret_version.APP_SECRET_VALUE) and no changes to existing resources unless you wire this secret into them.

AWS Introduction

AWS Pricing

AWS Threats

AWS Misconfigurations

Kms secrets manager in use remediation

Triage and Remediation

Remediation

1. Choose or Create a KMS Key for Secrets Manager

2. Create a Secret in AWS Secrets Manager

3. (Recommended) Enable Automatic Rotation

4. Update Applications to Use Secrets Manager Instead of KMS/Plaintext

A. Grant the Application IAM Permissions

B. Update Code to Call Secrets Manager

5. Decommission Old Secret Storage

6. Verify Remediation

1. Choose or create a KMS key for Secrets Manager

2. Create the secret in Secrets Manager

3. (Optional) Enable automatic rotation for the secret

4. Update application to read from Secrets Manager (CLI test)

5. Remove old KMS-based / plaintext storage

6. Lock down IAM so secrets must live in Secrets Manager

1. Prerequisites

2. Create a Secret in AWS Secrets Manager (using KMS)

3. Retrieve the Secret from Secrets Manager in Your App

4. (Optional) Enable Automatic Secret Rotation

5. Decommission the Old KMS-Based Storage (If Applicable)

6. IAM Permissions (High-level)

​Triage and Remediation

​Remediation

​1. Choose or Create a KMS Key for Secrets Manager

​2. Create a Secret in AWS Secrets Manager

​3. (Recommended) Enable Automatic Rotation

​4. Update Applications to Use Secrets Manager Instead of KMS/Plaintext

​A. Grant the Application IAM Permissions

​B. Update Code to Call Secrets Manager

​5. Decommission Old Secret Storage

​6. Verify Remediation

​1. Choose or create a KMS key for Secrets Manager

​2. Create the secret in Secrets Manager

​3. (Optional) Enable automatic rotation for the secret

​4. Update application to read from Secrets Manager (CLI test)

​5. Remove old KMS-based / plaintext storage

​6. Lock down IAM so secrets must live in Secrets Manager

​1. Prerequisites

​2. Create a Secret in AWS Secrets Manager (using KMS)

​3. Retrieve the Secret from Secrets Manager in Your App

​4. (Optional) Enable Automatic Secret Rotation

​5. Decommission the Old KMS-Based Storage (If Applicable)

​6. IAM Permissions (High-level)

Triage and Remediation

Remediation

1. Choose or Create a KMS Key for Secrets Manager

2. Create a Secret in AWS Secrets Manager

3. (Recommended) Enable Automatic Rotation

4. Update Applications to Use Secrets Manager Instead of KMS/Plaintext

A. Grant the Application IAM Permissions

B. Update Code to Call Secrets Manager

5. Decommission Old Secret Storage

6. Verify Remediation

1. Choose or create a KMS key for Secrets Manager

2. Create the secret in Secrets Manager

3. (Optional) Enable automatic rotation for the secret

4. Update application to read from Secrets Manager (CLI test)

5. Remove old KMS-based / plaintext storage

6. Lock down IAM so secrets must live in Secrets Manager

1. Prerequisites

2. Create a Secret in AWS Secrets Manager (using KMS)

3. Retrieve the Secret from Secrets Manager in Your App

4. (Optional) Enable Automatic Secret Rotation

5. Decommission the Old KMS-Based Storage (If Applicable)

6. IAM Permissions (High-level)