How to create and manage SecureString secrets in SSM Parameter Store for production

If you like sleep and you care about your on call life span this quick guide shows how to store encrypted secrets in AWS Parameter Store using a customer managed KMS key and the AWS CLI. No mystery or magic here just SSM SecureString, KMS encryption, and a tiny amount of IAM paperwork.

Step 1 Create or choose a KMS key

Use a customer managed key so you get audit logs and rotation control. In practice that means one key per security boundary. Separate keys for prod and staging will stop accidental cross environment secrets and keep your security team from typing angrily.

aws kms create-key --description MyAppKey

aws kms create-alias --alias-name alias/myAppKey --target-key-id 

Keep the key alias handy. You can use alias names in the CLI to avoid copying long key ids around.

Step 2 Store a SecureString parameter with the AWS CLI

Create the parameter with type SecureString and point it at the CMK alias you created. This stores the value encrypted at rest with KMS.

aws ssm put-parameter --name /prod/db/password --value SuperSecret123 --type SecureString --key-id alias/myAppKey

Yes that stores the secret. No do not paste actual production passwords into shared Slack channels. You know who you are.

Step 3 Grant SSM and KMS permissions

Two permission layers matter. The IAM principal that calls SSM must have ssm GetParameter and kms Decrypt permissions. The KMS key policy must allow the calling principals to use the key. In some setups you will also need to grant the SSM service principal use of the key depending on how you automate writes.

Check both the key policy and the IAM role or user policies. Least privilege applies. Granting everything to everyone is a valid quick way to sleep worse.

Step 4 Retrieve the parameter with decryption

When you pull the value include the with decryption flag. This tells SSM to call KMS for the data key so you get the plaintext back in your shell. Avoid printing secrets to logs or sharing them with the entire planet.

aws ssm get-parameter --name /prod/db/password --with-decryption --query Parameter.Value --output text

Best practices for devops and secret hygiene

• Use descriptive names that include environment and purpose. Example format is slash env slash service slash name like /prod/myapp/db/password.
• Keep a separate key per environment to reduce blast radius and to simplify audits.
• Automate rotation. Pair KMS key rotation with automated secret rotation using Lambda or Systems Manager Automation to avoid dramatic late night change requests.
• Use parameter policies for expiration and automatic versioning when that helps your workflow.
• Follow least privilege for IAM. The caller needs ssm GetParameter and permission to use the KMS key for decrypt. Audit those policies regularly.
• Never echo secrets to logs or leave them in shell history. That is not a security feature it is a bug with a cape.

Short recap

This guide covered creating or choosing a CMK, storing a SecureString parameter with the AWS CLI, granting the right IAM and key permissions, retrieving a decrypted value, and operational tips for rotation and naming. Do this and your ops team will love you or at least call you fewer times at night.