secrets-management

Topics in the source

• Secrets management
• 1. Prefer not having a secret at all
• 2. Never let a secret near the repository
• 3. Scope every credential narrowly
• 4. Make rotation routine, not an event
• 5. Know what to do when one leaks
• 6. Inject at runtime, hold in memory
• Report

A secret's danger is proportional to how many places it exists and how long it lives. Most practice focuses on the first storage decision and ignores rotation and revocation, which is where the real exposure sits — a key nobody has rotated in four years has been on more laptops than anyone can name. Assume every secret will eventually leak. Design so that when it does, the blast radius is small and the fix is one command. The best credential is one that does not exist. In order of preference: 1. Workload identity, the platform vouches for the service. IAM roles, service accounts, OIDC federation. Nothing to store, nothing to rotate, nothing to leak 2. Short-lived credentials issued on demand, expiring in minutes or hours 3. A long-lived secret in a manager, injected at runtime 4. A long-lived secret in an environment variable — workable, and the floor 5. A secret in a file in the repo, never Most cloud-to-cloud authentication can use option 1 today, and teams keep using static keys out of habit. That is the single biggest available improvement. Done when: every static credential has been checked for a workload-identity alternative. Not in code, config, or a committed .env. Commit a

This is an excerpt. Refer to the complete source and its current requirements.