Secrets Are Not Configuration

Why this matters

A cloud key ships in a public repo for eleven minutes before deletion, and bots collect it in four. Deletion feels like repair; rotation is the repair, because copies are already everywhere. Or credentials ride in environment variables through shared logs into the log store for a year. The exposure already happened at commit time; everything after is response speed. The M04 fictional-secret lesson returns here with production stakes.

Concepts

Three channels by sensitivity, enforced by mechanism, not intention. Code in the repo, reviewed and versioned. Non-secret configuration in environment or mounted files per environment, exactly as M05 lesson 3 separates. Secrets in the platform's secret store or a mounted file with tight modes, referenced by name, masked in logs, rotated on schedule. Anything that reaches a fourth place (chat, ticket, slide, image layer) is an incident with a known response, not a shortcut.

Committed means exposed, always. Git history preserves every version, forks copy it, registries keep every layer, and scanners plus attackers watch public pushes continuously. The response order is fixed: revoke and rotate first (stop the bleeding), audit what the credential touched (scope the damage), remove from history as hygiene (never as the fix), then write the postmortem on how it got there. Rotating last or never is the actual breach; deleting first is theater that leaves the key valid.

Rotation must be boring to be reliable. Short lifetimes and automated rotation turn exposure from emergency into routine: a leaked hourly credential dies on its own, while a leaked eternal key lives until someone notices. Design for rotation from day one (no hardcoded credentials, reload without restart where possible), because retrofitting rotation during an incident is how outages stack on breaches.

Detection closes the loop. Secret scanning on every push, audit of who read which secret when, and alerts on impossible usage (a dev key from a foreign network at 4am). Scanning finds the accident fast; the response order above makes the finding cheap. A finding with no practiced response is just bad news delivered faster.

Worked example

A database password appears in a committed config file. The response:

1. Rotate the password at the database; confirm the app reconnects. 2. Audit connections during the exposure window for unknown clients. 3. Purge the file from history and rotate anything else in the same commit. 4. Move the password to the secret store; reference by name; postmortem.

Expected reading: service continuity first (rotate, reconnect), damage scoping second (audit), hygiene third (purge), prevention last (store plus review). Deleting the file first would have left a valid password in unknown hands. Lab L22's narrowed user plus this response order is the complete local story: small reach, fast rotation.

The common wrong move

Base64 as protection, or splitting secrets across files as obscurity. Encoding is not encryption and scattering is not access control; both read instantly to anyone with read access. Real controls are the store, the modes, the rotation and the audit. If reading the secret requires only reading the repo, there is no control, only hope.

Lab and next step

Lab L22's environment uses fixture credentials throughout, rotated as part of the narrowing proof. Next, lesson 3 triages the findings scanners produce: dependencies and images with known holes, ranked by risk, fixed by what works.