The standard advice for keeping credentials out of a codebase is to inject them as process environment variables at deployment time. What does that injection actually guarantee, what does it not guarantee, and what does it imply about rotating the value?

## What the mechanism is Environment injection means the deployment substrate — an orchestrator, an init system, a platform runtime — sets key/value pairs in the process's environment block at launch, and the application reads them at startup instead of reading a literal from its own source or bundled config. The credential's location moves from the build-time artifact to the run-time deployment description. ## The one property it guarantees **Artifact/configuration separation.** The compiled or packaged artifact is now identical across development, staging and production, and it contains no credential to leak through version control, a registry, a decompiler or a string dump. This is genuinely valuable and it is the reason the advice is standard: it eliminates the whole family of leaks that come from a credential being *inside the thing you distribute*. It is also what makes promotion (build once, deploy many) safe. ## The properties it does not provide 1. **Confidentiality on the host.** The value is plaintext. Anyone who can read the process's environment can read it — the same user, a debugger, an administrator, a sidecar container sharing the namespace, or anything with access to the operating system's process introspection interface. 2. **Containment across processes.** Environment is inherited by default. A shell-out, a build step, a plugin or a crash handler launched by your process starts life holding your credentials, which is how values escape into logs and reports that nobody intended to expose. 3. **Protection from your own diagnostics.** Startup banners that print configuration, exception reporters that attach environment, `env`-style debug endpoints, container inspection output and job logs all serialise the environment routinely. The audience for logs is almost always broader than the audience for the credential. 4. **Protection of the deployment description.** The value has to be written somewhere for the substrate to inject it, and that somewhere — a manifest, a pipeline variable, a platform setting — is a store subject to the same test as any other: who can read it, is it replicated, is it retained in revision history? 5. **Scoping or attribution.** Injection says nothing about whether the credential is narrowly privileged or shared by forty services. ## The rotation implication This is the part candidates usually miss. The environment block is read **at process start** and is effectively immutable afterwards from the application's point of view. Therefore: - Rotating the value requires **redeploying or restarting** every consumer. - Because a restart is disruptive, the issuer must support **two valid generations** at once, or the cutover is an outage. - Rotation cadence collapses to deployment cadence, so "we'll rotate quarterly" quietly becomes "we rotate when someone remembers". The usual escalation path follows directly: if you need frequent or automated rotation, the process must be able to *re-read* the credential — from a broker it queries with a refresh, from a file the substrate rewrites and the process watches, or from platform-issued short-lived credentials that are re-minted continuously. Each of those replaces "rotation as an event" with "issuance as a mechanism". ## Where it sits on the defence ladder Using the ordering that runs from guarantee to heuristic — structural separation, then transformation, then scope-and-lifetime policy, then detection — environment injection is a *partial* structural separation. It removes the credential from the artifact but not from the host, and it introduces no key hierarchy, no expiry, and no audit. Compare it to a runtime identity the platform attests to, where the workload proves what it is and receives a short-lived credential it never stores: that removes the durable bearer value entirely. Environment injection keeps a durable bearer value and merely relocates it. ## When it is nonetheless the right call It is fine, and often correct, when the credential is narrowly scoped, the blast radius of its disclosure is small, rotation is rare and cheap, and the host is not shared with untrusted workloads. It is a poor fit for high-privilege credentials, long-lived shared secrets, multi-tenant hosts, and anything you intend to rotate on a schedule. ## Practical hygiene that follows from the analysis Redact by default in logging and error reporting rather than by blacklist; never log the whole configuration at startup; do not pass credentials as command-line arguments, which are even more visible than environment; keep credential values out of shell histories and process wrappers; and treat the deployment manifest that carries the value as a secret-bearing store with its own access control and history, because it is one.