Best practices for SecureString in Parameter Store with KMS and IAM

Quick recap for people who skipped the meeting

SSM Parameter Store can hold plain text values if you are brave, or SecureString values if you prefer your secrets to stay secret. Use a customer managed KMS key to control rotation and access, grant only the roles that need to decrypt, and use CloudTrail to catch the suspicious stuff. This guide shows practical steps with the AWS CLI and sensible defaults so you do not end up explaining how a password leaked to the interns.

Step 1 Create or select a KMS key for encryption

Customer managed KMS keys give you control over rotation and key policy. Create a key and give it a friendly alias so your commands do not look like computer gibberish.

aws kms create-key --description 'SSM parameter key'
aws kms create-alias --alias-name alias/ssm-params --target-key-id example-key-id

Use an alias for day to day commands and enable automatic rotation when appropriate. If you like drama you can rotate manually, but most teams prefer slightly less chaos.

Step 2 Store a SecureString parameter with the AWS CLI

Encrypt at rest by telling SSM which KMS key to use. Use the alias or the key id. Keep values out of terminal history if you are serious about security.

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

If you are automating this from CI avoid plain text values in logs and use parameter store put calls from ephemeral runners.

Step 3 Grant least privilege access via IAM and key policy

Two places control decrypt access. The KMS key policy and the IAM permissions of the role or principal. Grant the KMS decrypt permission to only the application roles that need it. Also allow the SSM service principal to use the key if needed by SSM actions.

• Attach KMS decrypt to your application role.
• Limit the key policy to the SSM service and specific IAM roles.
• Avoid wildcards that invite mischief and accidental access.

Step 4 Retrieve the parameter decrypted when the app needs it

When your process runs, request the parameter with decryption enabled. This requires the role to have both ssm get permission and KMS decrypt permission at the right time.

aws ssm get-parameter --name '/prod/db/password' --with-decryption

Do not persist decrypted secrets to disk unless you have a good reason and an audit trail. Memory is ephemeral and your logs are permanent.

Step 5 Audit and rotate so your security team smiles

Use CloudTrail to log parameter and KMS calls. Enable KMS automatic rotation when it fits your compliance rules. Regular rotation and audits reduce the blast radius when things inevitably go wrong.

Practical tips and common pitfalls

• Use aliases for friendly CLI usage and easier key swaps.
• Do not grant decrypt to broad principals. Least privilege is not negotiable.
• Monitor CloudTrail for unusual get requests and configure alerts.
• Keep parameter names consistent and environment specific to avoid accidental reads.
• Use IAM roles for compute resources rather than embedding credentials in code.

Wrap up

Parameter Store with SecureString and KMS gives you encrypted secrets with an audit trail and controlled access. Combine AWS CLI commands for setup, tight IAM and key policies for access control, and CloudTrail plus rotation for ongoing hygiene. Follow these steps and your secrets will be safer, your ops team will be less nervous, and you will avoid awkward all hands meetings where someone explains how a password ended up in a pastebin.