Automate AWS Secrets Rotation

Automates rotation of secrets, credentials, and API keys using AWS Secrets Manager and Lambda. It covers creating secrets for RDS, DocumentDB, Redshift, and ElastiCache database credentials as well as third-party API keys, OAuth tokens, SSH keys, and custom credentials, using aws secretsmanager create-secret for both string and binary (file-based) secrets, and retrieving them with aws secretsmanager get-secret-value, including piping to jq for a specific field or base64 -d for a binary secret.

For automatic rotation it enables scheduled rotation via aws secretsmanager rotate-secret with a rotation Lambda ARN and an AutomaticallyAfterDays rule, triggers immediate or emergency rotation with --rotate-immediately, and checks rotation status with aws secretsmanager describe-secret. It provides a reference Lambda rotation handler implementing the four-step AWS rotation lifecycle (createSecret, setSecret, testSecret, finishSecret) for an RDS MySQL password, including a generate_password helper, and a custom rotation example for a third-party API key (Stripe) that creates a new key via the provider's API, tests it, then revokes the old key on finish.

For monitoring it sets up a CloudWatch alarm on the RotationFailed metric in the AWS/SecretsManager namespace, and includes a bash audit script that lists all secrets with their rotation status and schedule and flags any secret overdue for rotation, plus a Python compliance-report script that classifies secrets as compliant or non-compliant (rotation not enabled, never rotated, or not rotated within 90 days).

kiro-cli chat "Use aws-secrets-rotation to set up RDS credential rotation"

Use it to implement automated secrets rotation, manage credentials securely, or comply with security policies requiring regular key rotation - for RDS/DocumentDB/Redshift/ElastiCache credentials or third-party API keys and tokens. It is not a substitute for environment-specific validation, testing, or expert review, and it should stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Inputs are AWS credentials/CLI access to Secrets Manager, Lambda, RDS, and CloudWatch, plus the secret's name, current value, and rotation Lambda ARN where applicable. Output is a created or rotated secret in Secrets Manager, a deployed rotation Lambda, a CloudWatch alarm, a rotation-audit report printed to the console, or a compliance report listing compliant vs. non-compliant secrets with the specific issue per secret.

Uses the AWS CLI (aws secretsmanager, aws cloudwatch), the boto3 Python SDK, and the AWS SDK for Node.js (aws-sdk) for application-side secret retrieval, with example integration code using pymysql and mysql client libraries to consume the retrieved credentials. It can be driven through Kiro CLI. Stated best practices cover planning (identify secrets, define 30/60/90-day schedules, test in non-production, document procedures, plan for emergency rotation), implementation (use AWS-managed rotation where possible, add error handling and CloudWatch monitoring, test application compatibility, roll out gradually), and operations (monitor success/failure, alert on failures, run regular audits, maintain rotation runbooks).

Cloud security and platform engineers who need to set up, monitor, or audit automated credential rotation for AWS-managed or third-party secrets, including emergency rotation after a suspected compromise.