Module 5 · Secrets Management 🔒

Every application has secrets — database passwords, API keys, TLS certs, encryption keys, third-party tokens. Where you store them determines whether a compromise is contained or catastrophic. This module covers secrets-management patterns for modern cloud applications.

The problem

Secrets historically lived in: environment variables, config files, source code, shared spreadsheets, Slack messages, CI/CD logs. Each is a leak vector. Secrets exposed in any of these = full compromise of whatever they protect.

Where secrets leak

• Git commits — AWS keys in .env files; ~1 in 500 commits to public GitHub leaks a secret
• Docker image layers — secrets via COPY / ENV persist in history even if later removed
• CI/CD logs — echo statements with credentials
• Error messages + stack traces — credentials in connection strings
• Server logs — requests with API keys in query strings
• Lost/stolen laptops — ~/.aws/credentials, config files
• Insider threats — departing employees with credentials in password managers

Managed secret stores — the solution

Core patterns

1. Runtime fetch

Application starts → authenticates to secret store via workload identity (IAM role / Managed Identity / Service Account) → fetches current secret → uses it. Never a secret on disk or in env.

# Python — fetch at startup
import boto3, json
client = boto3.client('secretsmanager')
secret = json.loads(client.get_secret_value(SecretId='prod/db')['SecretString'])
db_password = secret['password']