25 lines
1.8 KiB
Markdown
25 lines
1.8 KiB
Markdown
# Diagnosis — 2026-09-21
|
|
|
|
1. The constraint is real and where the report put it: a module requires a provision name once,
|
|
a pair credential is keyed on (name, consumer node, consumer module, provider), and the login
|
|
the vault derives is keyed on the (node, module) pair. Two secrets for one module and one vault
|
|
collide on every key.
|
|
2. The third question was answered by reading the catalogue as it is today: nine modules hold two
|
|
or more own secrets besides their broker account. Two hold a relay user beside a relay
|
|
password — the user is a name, not a secret, and could travel as configuration. The other
|
|
seven hold genuinely independent values with independent lifetimes: an internal token beside
|
|
an admin password; a source, an admin and a relay password; an admin password beside an API
|
|
token; a root certificate, its key, that key's password and an intermediate's. None of those
|
|
derives from another. So "one value per module, derivation the module's business" is not an
|
|
answer for most of them.
|
|
3. So the answer is neither option as the report framed them. A module keeps one `secret`
|
|
provision per independent value, and needs a way to require the same provision name more than
|
|
once under distinct local names — the way `secrets:` already maps a provision to a path. That
|
|
is a manifest-vocabulary decision, and it moves the pair key: the credential must be keyed on
|
|
the local name, not the provision name, or the second pair overwrites the first.
|
|
|
|
**Located in:** the manifest's `secrets` vocabulary (the catalogue parser) and the pair
|
|
credential's key (the controller's secret store). Fixed as
|
|
[ADR 0094](../../02-DECISIONS/0094-a-module-may-hold-several-secrets-from-one-provider.md): the
|
|
key gains the local name, empty for every existing pair, so nothing that exists changed.
|