jschoubben
ec7b6e0748
Closes issue 041 by decision and by code on the same branch: the catalogue engine refuses a secret in a container's env, and a secret-carrying env-file unless the container declares its reason; the controller reads all six of its credentials from files; design 13 states the rule and how it is checked.
4.6 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| resolved | 2026-09-10 |
|
ADR 0086; mesh-controller feat/secret-not-in-environment (envfile twins for the broker settings, catalogue refusal of secrets in env / undeclared env-file); mesh-catalog (the controller reads its six credentials from files; 35 containers declare their exception); mesh-host (the installer delivers any MESH_…_FILE own secret) | 03-DESIGN/01-to-be/13-credentials-and-their-rotation.md |
041 — A credential the mesh took care to seal ends up in the process environment
Symptom
The mesh generates a module's own secret, seals it to the machine and discards the plaintext —
it cannot read the value back even if asked. The host unseals it into a file the module names, at
0600.
Then the module hands it to its container as an environment variable, and the runtime puts it
where anything on that machine that can talk to the runtime can read it: docker inspect prints
it, and /proc/<pid>/environ holds it for the life of the process.
Observed while making the control plane an ordinary module. Its store connections were moved to
files, read by a …_FILE variable naming the path. Its broker credentials have no such variable,
so they are still delivered through an env-file — which the runtime turns into exactly the
environment above. Same credential handling, same machine, two different exposures, decided by
whether the program that reads it happens to accept a path.
Why this matters
The care taken elsewhere is what makes this stand out. Sealing to a machine and discarding the
plaintext is expensive and deliberate: it exists so that a credential is readable only where it is
used. Handing that same value to the runtime as an environment variable gives it back to anything
that can run inspect — and inspect is a routine operation. It lands in support output, in
captured logs, in a screenshot of a terminal, and in any tooling that dumps container state.
It is not a module's mistake. Nothing in the manifest format is being misused: placing a secret
into an env-file with ${secret:…} is a supported shape and other modules use it. So each module is
correct on its own, and the property — a sealed credential is not readable by everything on the
machine — holds or fails per variable, by accident of what each program accepts.
And the two halves now disagree inside one module. The control plane reads its store connection
from a file and its broker credential from the environment. A reader cannot tell from the manifest
which secrets are protected from inspect and which are not, because the manifest looks the same
either way.
Open questions
- Should every program the mesh runs accept a path for anything secret — a
…_FILEtwin as a convention rather than a thing each program decides? That is a small change in several programs and a large one in what the manifest can promise. - Should the manifest layer refuse
${secret:…}inside a container'senv, or inside anenv-file, once a path-shaped alternative exists? A rule nothing enforces is the shape this repository keeps finding. - Is there a case where the environment is genuinely the only channel — a program that cannot be changed and reads no file? If so, what should the mesh say about that module, out loud, rather than treating it as equivalent?
- What is the actual reach of the exposure on a node — which identities can talk to the container runtime, and is that set smaller than "anything running as the operator"? The answer decides whether this is a hardening item or something sharper.
Reconciled 2026-09-21
Still open, and worse than reported: the controller's own manifest now delivers its store
connections and its broker credentials through an env-file, so both halves reach the process
environment; 28 catalogue manifests use env-file for a secret, and nothing in the catalogue
engine refuses a ${secret:…} placeholder in one. The vault work of
ADR 0085 rests on the seal this weakens.
Resolved 2026-09-21
By ADR 0086: a secret reaches a process as a file, an environment exception is declared with a reason, and the catalogue engine refuses the undeclared shape. The controller, the instance this was opened on, reads all six of its credentials from files. The 35 other containers carry a declared reason; converting each where its software accepts a path remains per-module work and is not this issue's.