Credentials at Runtime

## Storing a credential and delivering it are different problems Choosing where a credential **lives** — an access-controlled store, an encrypted file, a managed credential service — answers only half the question. The other half is how the value gets from there into a process that is already packaged and already scheduled. That last hop decides the **readership** of the value: how many parties end up holding a copy, how long each copy lasts, and what has to happen for the value to change. In practice there are three delivery shapes: 1. the value is **baked into the artifact** the workload ships as; 2. it is **injected at start-up** by whatever launches the workload; 3. it is **fetched by the process itself** once it is running. This question is about the first, which is the shape that gives a value the widest readership and the slowest rotation. ## The readership is the artifact's readership An image is an **immutable artifact**, identified by a content digest, built once and copied wherever it has to run. A credential inside it is simply bytes in that artifact, so the set of parties who can read the credential is exactly the set who can obtain the artifact: - anyone who can pull it from the registry it was pushed to, plus every mirror or regional copy made from that registry; - every host that runs the workload — the artifact is unpacked onto local disk there, so the value can be read without touching the running process at all; - every environment the artifact is promoted through, including the ones with looser access than production; - anyone who receives a copy later: an exported archive, an incident bundle, a vendor, a build cache, an old artifact retained for rollback long after the credential mattered. | Reader | How the value reaches them | Why it goes unnoticed | | --- | --- | --- | | Registry readers | An ordinary pull, then reading a file | Pulling is the expected everyday operation | | Host operators | The unpacked artifact on the node's disk | No access to the workload itself is required | | Holders of copies | Mirrors, exports, caches, support bundles | Copies are made routinely and rarely tracked | | Future readers | Old artifacts kept so a rollback is possible | Retention outlives the credential's usefulness | No exploit is involved anywhere in that table. Artifacts are designed to be readable — reading one is exactly what a host does in order to run it. Two defences usually appear at this point, and neither survives contact. **"The registry is private"** is access control over *distribution*, not confidentiality of a *value*: it governs who may pull today, says nothing about copies already pulled, and stops mattering the moment the artifact is mirrored, exported or re-pushed elsewhere. **"The value is encoded"** — a reversible encoding is not protection. If the process can use the credential at run time, everything needed to recover it ships in the artifact too. ## What changing the value costs The second half of the answer is the operational one, and it is usually what the interviewer is really after. Because the artifact is immutable and the value is part of it, changing the credential means: 1. building a new artifact that contains the new value; 2. pushing it; 3. rolling out every workload running the old artifact, in every environment, in an order that does not break callers. Rotation has stopped being an operational action and become a **release**, with a release's scheduling, review, approval and risk. The predictable outcome is that the credential is never rotated at all, and ages until it is older than half the people who know it exists. There is a second cost that is easy to miss. One artifact carries one value, so every environment that runs it shares that credential. There is no per-environment **blast radius**: a copy of the artifact that escapes from a low-trust environment is a production credential in someone else's hands. Splitting the value per environment means splitting the artifact per environment, which costs you the property that the thing you tested is the thing you ship. ## What to do instead Ship the artifact with no credential in it, and make the process **fail loudly at start-up** when none arrives rather than falling back to a built-in default — a default credential is a baked-in credential with better manners. Have the value delivered at start-up, or have the process fetch it itself; either keeps the artifact environment-neutral and turns the credential into an operational input that can change without a rebuild. And treat a credential that has ever been inside a shipped artifact as **exposed**. The fix is to rotate it at the source and retire the old value, not to publish a new artifact without it: every copy of the old artifact still exists wherever it was pulled, mirrored or archived, and none of those copies is under your control any more.