From d1aa4254c938a76b86811120e65643364b1cb9d3 Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 4 Sep 2026 22:23:24 +0200 Subject: [PATCH] =?UTF-8?q?Issue=20008=20=E2=80=94=20a=20provider=20runtim?= =?UTF-8?q?e=20has=20no=20seal=20key=20the=20mesh=20can=20deliver?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Found building the module-runtime vertical slice: a provider's provisioner requires a seal key it has no way to receive, and the consumer no way to obtain the matching one. The runtime cannot come up as delivered. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF --- .../00-report.md | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 04-ISSUES/008-provider-runtime-has-no-seal-key/00-report.md diff --git a/04-ISSUES/008-provider-runtime-has-no-seal-key/00-report.md b/04-ISSUES/008-provider-runtime-has-no-seal-key/00-report.md new file mode 100644 index 0000000..addfe98 --- /dev/null +++ b/04-ISSUES/008-provider-runtime-has-no-seal-key/00-report.md @@ -0,0 +1,67 @@ +--- +status: open +opened: 2026-09-04 +located-in: [] +fixed-by: +amended-design: +--- + +# A provider module's runtime needs a seal key the mesh cannot deliver + +## What was observed + +Building the vertical slice for the module runtime (the module runs its own code as its +own process under its own account), a **provider** module — one that stands up a per-consumer +resource and hands back a credential — was assigned to a node and run as a broker-bound +runtime. The runtime hosts the module's provisioner, and the provisioner's reconcile harness +opens with: + +- it requires a **seal key**, read from the environment, and fails immediately without one; +- every credential it produces for a consumer is **sealed to that key** before it is written. + +Nothing in the control plane delivers such a key to a module's runtime. The mesh delivers a +module its **broker account** (a sealed, machine-bound credential) and its **own-secrets**, +and it seals those deliveries with a key of its own — but there is no provision for handing a +provider the key it must seal *its own* outputs with, nor for a consumer to receive the +matching key to unseal them. + +The consequence has two faces, both bad: + +- **A provider runtime cannot start.** The harness treats the missing key as a hard, + up-front failure — correctly, because a provider that silently sealed to nothing would be + worse. So a provider module, assigned and pushed, comes up dead until a key is supplied + out of band. +- **Supplying one out of band is not a fix.** A key set by hand on the provider is a key the + consumer has no principled way to obtain. The seal is symmetric; the two ends must share + it, and there is nothing that makes them share it. + +The slice proved the mechanism only by setting a lab-local key in the manifest by hand — an +admission, not a solution. The test that does so says as much in its header. + +## Why it matters beyond this instance + +The module-runtime design (the ADR that says a module runs its own code under its own +account) is the model every provider now follows — a cache, an object store, a database, +each stands up per-consumer resources and returns sealed credentials. The delivery the mesh +already does for a broker account is exactly the shape a seal key needs, so the gap is not +that the idea is hard; it is that one required secret in the provider/consumer handshake was +never given an owner. Left open, every provider converted to the runtime model inherits a +module that cannot come up as delivered, and the failure lands at assignment time on whoever +is standing up the node — far from the design decision that caused it. + +There is also a **rule-with-no-check** here: the design states that a consumer receives a +sealed credential and unseals it. Nothing today establishes the key that makes "unseal" +possible, so the rule is, at present, enforced by nothing. + +## Open questions + +- Whose secret is the seal key — the mesh's, the node's, or the specific provider/consumer + grant's? The answer decides who generates it and who it is delivered to. +- Is it one key the mesh holds and delivers to both ends of every grant, or a per-grant key + minted when a grant is made? A per-grant key confines a leak to one consumer; a mesh-wide + key is one thing to deliver and rotate. +- Should it be delivered the way the broker account already is — a sealed, machine-bound + own-secret file the runtime reads — so a provider needs no new delivery channel, only a new + named secret? +- Does rotation of this key have to re-seal every outstanding credential, and if so, is that + the provisioner's reconcile loop's job or the control plane's?