> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Kms secrets manager in use remediation

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Using Console" defaultOpen="true">
        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

        1. Sign in to AWS Management Console.
        2. Go to **IAM** > left menu **Encryption keys (KMS)**\
           or directly open **AWS Key Management Service (KMS)**.
        3. In the left pane, select **Customer managed keys**.
        4. 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

        1. In the console, go to **AWS Secrets Manager**.
        2. Click **Store a new secret**.
        3. 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.
        4. In **Key/value pairs**, add your secret values (for example `username`, `password`, `apiKey`, etc.).
        5. Under **Encryption key**, choose:
           * **aws/secretsmanager** (AWS-managed)\
             or
           * Your customer-managed KMS key (e.g. `alias/secrets-manager-key`).
        6. Click **Next**.
        7. Enter a **Secret name** (e.g. `prod/db/credentials`).
        8. (Optional) Add a **Description** and **Tags**.
        9. Click **Next** to pass rotation for now, or configure it (see step 3).
        10. Review and click **Store**.

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

        ***

        ## 3. (Recommended) Enable Automatic Rotation

        1. In **Secrets Manager**, click the secret you just created.
        2. Go to the **Rotation** tab.
        3. Click **Edit rotation**.
        4. Check **Enable automatic rotation**.
        5. Choose **Create a new Lambda function** or **Use an existing Lambda function** to rotate the secret.
        6. Set the **Rotation interval** (e.g. every 30 days).
        7. 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:

        ```json theme={null}
        {
          "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)**:

        ```python theme={null}
        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:

        1. 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.
        2. 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

        1. In **Secrets Manager**, verify:
           * All required secrets exist.
           * They are encrypted with a KMS key.
           * Rotation is configured (if applicable).
        2. In **CloudTrail**, you should see `GetSecretValue` calls from your application role.
        3. 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.
      </Accordion>

      <Accordion title="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:

        ```bash theme={null}
        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.:

        ```bash theme={null}
        KMS_KEY_ID="arn:aws:kms:us-east-1:111122223333:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
        ```

        Optionally give it an alias:

        ```bash theme={null}
        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):

        ```bash theme={null}
        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:

        ```bash theme={null}
        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:

        ```json theme={null}
        {
          "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:

        ```bash theme={null}
        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:

        ```bash theme={null}
        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:

          ```bash theme={null}
          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):

        ```bash theme={null}
        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.
      </Accordion>

      <Accordion title="Using Python">
        To remediate “Secrets Manager should be in use” for secrets currently stored/managed via KMS, you essentially need to:

        1. Store the secret in AWS Secrets Manager (encrypted with KMS).
        2. Update applications to read from Secrets Manager instead of wherever they’re getting the secret now.
        3. 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:
          ```bash theme={null}
          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.

        ```python theme={null}
        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.

        ```python theme={null}
        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:

        ```python theme={null}
        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:

        1. Verify no application still reads the old data.
        2. Remove or redact old secrets (e.g., from SSM Parameter Store, config files, S3, etc.).
        3. Optionally schedule deletion of the KMS key if it was dedicated purely for that legacy pattern and is no longer needed:
           ```python theme={null}
           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.
      </Accordion>

      <Accordion title="Using Terraform">
        ```hcl theme={null}
        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.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>