4a1b2187062ab77d527bf50ba9456e085bcf4fa6
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
4a1b218706 |
Seats held by assignments, one assignment per module per node, and 0113's bottom of the stack
Decided with the author: - A seat is held by one assignment, not claimed by a definition. A definition says which seats a module can hold; an assignment says which it does. The store module can run on every node and one assignment holds mesh-store; moving a role changes an assignment, never a definition. The foundation's seats name what the mesh itself uses and route no consumer — database and amqp consumers use co-location, the holder included. This replaces the wrong rationale that the foundation's store is "provider to nobody", which contradicted ADR 0078 and to-be 21. 0079's one-postgres rule becomes one mesh-store holder. - A module is assigned at most once to a node. The instance identity in 0112 and 27 is withdrawn, and the login-length problem with it. Review fixes to 0113: - The bottom of the stack: the vault is installed as soon as the shared runtime base exists, and genesis generates everything needed until then — including the permanent controller's, the control-node agent's, the builder's and the broker provisioner's bus accounts, and the controller's store login. Genesis creates those accounts until the broker's provisioner runs and adopts them. - Genesis's values are delivered recorded as the mesh's own, so 0092's never-replace rule for operator values does not make them unrotatable. - Backend-issued secrets (a forge's once-only API token) enter through the vault. Non-module parties (the controller's logins, node agents' accounts) are answered the same way, the controller asking on their behalf; an enrolment token reaches the controller only as what verifies it. - A secret with no provisioner to apply it is marked not rotatable by the mesh and refused, instead of a restart reported as done. Unused password generators in six provider clients are removed, and a catalogue scan checks no module mints. - Rotation's lock-out cases (offline reader, bus account owner, restarted provisioner) are recorded as open, with overlap and re-confirm-with-safeguards as the two answers, to be chosen before acceptance. 0110, 0111 and 26 are marked proposed: they changed in meaning and are under review, and an accepted record must not rest on proposed ones. To-be 23 and the glossary are restored to main; they change when these records are accepted. |
||
|
|
1b5f2c2c1a |
ADR 0113 and to-be 27: address the review of the vault rework
Two decisions taken with the author: - Genesis delivers and the vault adopts. The vault cannot run first — it is built on the runtime base the installation makes after the store, broker and controller, and it learns its work over the bus. Genesis generates the foundation's first shared secrets, seals them to the operator key, and delivers them to the vault through the path an operator's value takes; from then on the vault holds and rotates them. This answers ADR 0085's own reason for rejecting vault-only minting, which 0113 now names instead of stepping around. - Rotation re-confirms on every pass. An applier repeats its confirmation until acknowledged, so a lost message costs one pass; an applier that stops after applying locks readers out until its supervised restart, and that window is stated and shown, not claimed away. Fixes: - Scope: a shared secret is made by the vault; a private key (node sealing keys, the operator's key, the certificate authority) is made where it is used. The inventory adds the makers the first version missed: node and builder broker passwords, and enrolment tokens. - Broker accounts are created by the broker's provisioner, not the controller, so the controller never holds their plaintext; mesh-broker delivers amqp again — one broker per mesh — and only mesh-store delivers nothing. - secret is a reserved provision: only the mesh-vault holder may provide it, and no pin routes around it. - A secret's contract says whether a recipient applies it or reads it at start; appliers are never restarted for it, init-only secrets are applied, and confirmation is to-be 13's standard. - Operator secrets are one rule everywhere: a secret requirement answered by the vault (0112 no longer says otherwise). A data provider's adapter may return fields; the data-return check names a lab consumer. - 'Holder' now means a seat's holder only; a secret has recipients. |
||
|
|
fa2c09a2c5 |
ADR 0113 and to-be 27: the vault makes every secret — provisioning all the way down
A secret comes into being seven ways today: provider credentials, own secrets (54 modules), broker accounts through a command that is easy to forget, a vault that only records what the controller mints (6 modules), operator values, licences, and root secrets. The vault was built to end own secrets and did not; the old path was never retired. 0113 is rewritten as a waterfall. The vault makes every secret and nothing else does. A provider that needs a secret for a consumer requires it from the vault, declared once in its provision's contract and expanded per consumer by resolution; the vault delivers it to both holders, each sealed to its own node, so a provider's code is unchanged. Own secrets, broker passwords, operator values and licence credentials take the same path. Genesis is not an exception: it raises the vault first and asks it, so there is one way a secret is made from the first one on. The vault can sit at the bottom because it requires nothing but a broker account. One shared mint function in the SDK was considered and rejected: generation becomes uniform but custody stays spread over every provider's machine, and each SDK language needs its own implementation. Rotation is asked of the vault and is provider-first: the value goes to the holder that accepts it, which confirms, before the holder that presents it gets it, so the lockout window shrinks to the consumer's own restart, and an unconfirmed provider holds the rotation rather than half-doing it. The host derives which processes to restart or recreate from the requirement a definition reads, so no definition declares restart-on for a secret. A rotation shows unconfirmed until each consumer restarted and passed its health check. Issue 103 becomes a prerequisite. The file is renamed to match what it now decides. 0112 follows. |