AWS Secrets Manager
Centrally manage and rotate database credentials and API keys
Secrets Manager is like a password manager for your applications. Instead of hardcoding database passwords or API keys in your code (terrible idea; anyone who sees the code sees the secrets), you store them in Secrets Manager. Your application asks Secrets Manager for the password at runtime, and Secrets Manager provides it securely. Secrets Manager can also automatically rotate passwords; change your database password every 30 days without you lifting a finger. It's like having a security guard who not only protects your keys but also changes the locks regularly to keep things secure.
Secrets Manager stores, encrypts (using KMS), and rotates secrets (passwords, API keys, tokens). Secrets are versioned; when rotated, old versions remain accessible during transition periods. Automatic rotation uses Lambda functions to change credentials in both Secrets Manager and the target service (RDS, Redshift, DocumentDB).
Key Capabilities
Key features: fine-grained IAM policies (control who can access which secrets), resource-based policies, VPC endpoints (access without internet), and CloudTrail logging (audit secret access).
Gotchas & Constraints
Gotcha #1: Rotation requires Lambda functions; AWS provides templates for RDS, but custom secrets need custom Lambda functions. Gotcha #2: Applications must handle rotation gracefully; use connection pooling and retry logic to handle credential changes. Constraints: Maximum secret size is 65KB, rotation frequency minimum is 1 day, and secrets are regional (must replicate for multi-region).
A SaaS application connects to 20 RDS databases with hardcoded passwords in configuration files, a security nightmare. They migrate to Secrets Manager, storing each database password as a secret. They update application code to retrieve passwords from Secrets Manager at startup using the AWS SDK. They enable automatic rotation for all RDS secrets; Secrets Manager rotates passwords every 30 days using Lambda functions that update both Secrets Manager and RDS. For API keys (Stripe, Twilio), they store them in Secrets Manager and grant access only to specific IAM roles. They use resource-based policies to allow cross-account access; a Lambda function in the dev account can access secrets in the prod account (with approval). CloudTrail logs show every secret access, and they create CloudWatch alarms for unusual access patterns. When a developer leaves, they rotate all secrets they had access to.
The Result
no hardcoded secrets, automatic rotation, and full audit trail.