58 lines
3.4 KiB
Markdown
58 lines
3.4 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-20
|
|
located-in: [mesh-controller internal/catalogue (requires/secrets), mesh-controller internal/inventory (secret key)]
|
|
fixed-by: ADR 0094; mesh-controller feat/several-secrets (secrets: under local names, the pair keyed on the local name, migration 0027); proven by the vault bed
|
|
amended-design: 03-DESIGN/01-to-be/24-the-secrets-vault.md
|
|
---
|
|
|
|
# One `secret` provision yields one value, and a module may need several
|
|
|
|
## Symptom, as observed
|
|
|
|
[ADR 0085](../../02-DECISIONS/0085-a-secret-is-a-provision.md) makes a module's own secret a
|
|
provision: the module requires `secret` from a vault and reads the pair credential the mesh
|
|
minted for that consumer↔vault pair. A pair has **exactly one** credential — that is the property
|
|
[13](../../03-DESIGN/01-to-be/13-credentials-and-their-rotation.md) is built on, and the reason
|
|
rotation touches one holder and nothing else.
|
|
|
|
A module may only require a provision name once, so a module that requires `secret` receives
|
|
**one value**. Counted across the catalogue at the time of writing, a module's own secrets other
|
|
than its broker account number as follows:
|
|
|
|
| own secrets | modules |
|
|
|---|---|
|
|
| one | 22 |
|
|
| two | 6 (an internal token and an admin password, a user and a password for an outbound mail relay, …) |
|
|
| three or more | 4 (a source, an admin and a relay password; a root certificate, its key and that key's password; …) |
|
|
|
|
Ten modules cannot be migrated onto the vault as designed, because the design gives them one
|
|
value where they hold two or more, and nothing in the record says what they should do instead.
|
|
|
|
## Why it matters beyond this instance
|
|
|
|
- **The migration in ADR 0085 is "module by module, not a flag day"** — but for a third of the
|
|
modules with own secrets there is no target to migrate to, and the gap is silent: such a
|
|
module keeps `own-secrets` for the rest and looks migrated.
|
|
- **Two candidate answers pull in different directions and neither is recorded.** A module could
|
|
derive several keys from its one value (a key-derivation step inside the module, which puts
|
|
cryptography into every module that needs two secrets), or the mesh could let a consumer
|
|
require several *named* secrets from one vault (which is a pair with several credentials, the
|
|
thing 13 deliberately does not have, or several pairs between the same two modules, which the
|
|
identity derivation in [ADR 0049](../../02-DECISIONS/0049-a-consumers-identity-fits-the-tightest-backend.md)
|
|
cannot express).
|
|
- **A secret with structure is not one value either.** A certificate authority's root
|
|
certificate, key and key password are three things with one lifecycle; a value the controller
|
|
mints at random is none of them. The vault's third species — an operator-delivered secret — is
|
|
the nearer fit, and it has its own gap ([070](../070-an-operator-cannot-deliver-a-pair-credential/00-report.md)).
|
|
|
|
## Open questions
|
|
|
|
- Is "one value per module" a rule to keep, with derivation the module's business, or does a
|
|
consumer name several secrets and the vault serve each as its own pair?
|
|
- If the latter: what is the login of the second pair between the same consumer and the same
|
|
vault, given that a login is derived from the (node, module) pair and is what the secret is
|
|
keyed on?
|
|
- Which modules genuinely need several independent secrets, and which hold two names for one
|
|
thing (an admin password and a token that is only ever set from it)?
|