---
status: open
opened: 2026-09-10
located-in: []
fixed-by:
amended-design:
---

# 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 `…_FILE` twin 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's `env`, or inside an
  `env-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.