Managing secrets outside the repository

Goal

Keep credentials out of anything that gets copied, shared, or indexed, and make replacing a compromised secret a routine operation.

Prerequisites

A storage location with access control (a secrets manager, or at minimum environment files with restrictive permissions on the host) and a deploy path that injects the values. The Twelve-Factor methodology requires a strict separation of config from code. As a litmus test, it asks whether the source code could be made public at any time without exposing credentials. The OWASP cheat sheet divides the topic into a lifecycle (creation, rotation, revocation, expiry), plus access control, auditing, handling in CI/CD pipelines, detection, and incident response.

Steps

1. Inventory your secrets: database passwords, API keys, signing keys, tokens. Assign each one an owner and a rotation interval.
2. If secrets are present in the repository history, remove them and then rotate them: a removed commit is not a revoked secret.
3. Inject secrets at runtime through the environment or mounted files, and keep an example file with empty values in the repository. The cheat sheet warns against hard-coding values in ENV or ARG instructions of a Dockerfile, because they easily leak through the container definition; the orchestrator sets the value at startup.
4. Scope tightly: one secret per service and environment, with minimal privileges. Where the platform supports it, use short-lived, dynamically generated credentials instead of long-lived static ones.
5. Never log them: build log records from allowed fields, and verify that error handlers do not output request headers or environment variables.
6. Set up detection: a secret scanner in CI and over the repository history, plus a documented procedure for what happens on a hit (revoke, rotate, review usage).
7. Rehearse rotation until it is a documented, tested procedure rather than an emergency; this includes break-glass access and recovery of the storage location.

Expected result

A fresh clone contains no secrets; a leaked log or backup reveals none; a rotation completes without downtime.

Limits and test basis

Environment variables are visible to the process and its children and can be captured by crash reporters; files with strict permissions or a secrets manager are stronger. Secret scanning in CI catches mistakes, not design flaws. This guide follows the cited sources; whether scheduled rotation uncovers unknown consumers of a secret is recorded in the wiki as a hypothesis.