From 8cb416e82afb9c65b3760e0a26bfb4d1ce0ce19c Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 31 Oct 2026 14:06:31 +0100 Subject: [PATCH] NK-WP-0056-T02: founder chose the executor runtime owner; owner requests sent net-kingdom writes the executor, a new rapp-* package deploys it (hub decision 6d1adce9). Requests to approval-engine, access-engine, secrets-engine, railiance-platform, audit-core, glas-harness and railiance-apps recorded with an answer table. Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 994874@bnt-lap001 Assistant-Session: 6017c416-d619-47eb-bd1a-f670a02d7d87 --- WORK-RECORDS.md | 2 +- .../2026-10-31-nk56-t02-owner-requests.md | 93 +++++++++++++++++++ workplans/NK-WP-0056-bounded-executor-path.md | 10 +- 3 files changed, 103 insertions(+), 2 deletions(-) create mode 100644 docs/proposals/2026-10-31-nk56-t02-owner-requests.md diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 8ac6192..0e8ba0d 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -341,7 +341,7 @@ | task | NK-WP-0055-T15 | done | — | workplans/NK-WP-0055-security-platform-production-readiness.md | | task | NK-WP-0055-T16 | wait | — | workplans/NK-WP-0055-security-platform-production-readiness.md | | task | NK-WP-0056-T01 | done | — | workplans/NK-WP-0056-bounded-executor-path.md | -| task | NK-WP-0056-T02 | todo | — | workplans/NK-WP-0056-bounded-executor-path.md | +| task | NK-WP-0056-T02 | wait | — | workplans/NK-WP-0056-bounded-executor-path.md | | task | NK-WP-0056-T03 | todo | — | workplans/NK-WP-0056-bounded-executor-path.md | | task | NK-WP-0056-T04 | done | — | workplans/NK-WP-0056-bounded-executor-path.md | | task | NK-WP-0056-T05 | done | — | workplans/NK-WP-0056-bounded-executor-path.md | diff --git a/docs/proposals/2026-10-31-nk56-t02-owner-requests.md b/docs/proposals/2026-10-31-nk56-t02-owner-requests.md new file mode 100644 index 0000000..893aa6c --- /dev/null +++ b/docs/proposals/2026-10-31-nk56-t02-owner-requests.md @@ -0,0 +1,93 @@ +# NK-WP-0056-T02: owner requests for the bounded executor (2026-10-31) + +Basis: Bounded Execution Admission v0.1, proposed (`canon/standards/bounded-execution-admission_v0.1.md`, +net-kingdom `989d5d4`), and its examples in `examples/bounded-execution-admission/`. The first live use is +NK-WP-0056-T06: unattended rotation of the `svc-authelia` directory bind, under one founder admission +(`bind-rotation-svc-authelia.yaml`). + +**Founder decision 2026-10-31 (hub `6d1adce9`):** + +- net-kingdom writes the executor runtime: source and tests, next to the admission validator, the bind + lanes and the synthetic journey; +- a new `rapp-*` package builds the image and deploys it in `sso` (ADR-0015); +- glas-harness becomes the path for agent executors later (GLAS-WP-0018). + +Every answer below is the owner's agreement. Nothing here assigns work to another repository. + +| Component | Owner (hub agent) | Asked to carry | Answer | +| --- | --- | --- | --- | +| Admission carrier | approval-engine | The admission as a consumable approval | pending | +| Admission as input claim | access-engine | Policy decision for executor operations under an admission | pending | +| Executor credential lanes | secrets-engine | Lifecycle of the executor's OpenBao credentials | pending | +| OpenBao roles and CCR types | railiance-platform | Kubernetes auth role and policies for the executor; CCR request types | pending | +| Receipt holder | audit-core | Execution-attribution receipts from the executor | pending | +| Agent executors | glas-harness | Session contract so a harness-launched agent can be an executor | pending | +| Runtime package | railiance-apps | Where the new `rapp-*` package lives and who creates it | pending | + +## approval-engine + +1. **Binding.** Can an approval carry a `BoundedExecutionAdmission` with these fields? + - `action: bounded-execution` + - `actor`: the executor identity (pilot: `service:nk-bind-executor`) + - `principal`: the approver (`admin`) + - `purpose`: `spec.purpose` + - `target: {admission_id, admission_digest}` + - validity equal to `spec.window` + + The plan, plan digest, budget and ceiling are inside the digested document, so `target` covers them. +2. **Assurance.** How does an approval record that the approver acted at `aal2`? The standard requires + it (BEA-C4). +3. **Consume.** The executor's service principal consumes once, before its first step. Which scope and + which `request_digest` does that take? Your contract notes that `consume` does not check digest + equivalence, so we plan an independent `GET /v1/approvals/{id}` comparison of + `target.admission_digest`. Is that the reading you intend? +4. **Revocation.** Can the founder revoke an approval that has not been consumed? This would be the + kill switch before the start (T07). + +## access-engine + +1. Should a PDP decision gate executor operations? For example: "executor X may run operation O on + target T under admission A", with the admission read as an input claim through approval-engine. +2. If yes, what is needed: a `bounded-execution` action, a policy pack and its owner, and the + `execution_contract` coverage that your current apply rules do not evaluate. What is the timeline? +3. For the T06 pilot, is it acceptable that the executor enforces the ceiling locally (validator plus + a Kubernetes Role), with the PDP check added later? + +## secrets-engine + +1. The pilot executor needs these OpenBao capabilities, at most 15-minute TTL: + - write the next version of `platform/workloads/net-kingdom/directory-binds/svc-authelia` (CAS); + - read it and `.../synthetic-journey/syn-journey` for its checks. + + Does secrets-engine orchestrate these lanes for an executor workload, as with other lifecycle lanes? +2. To set `svc-authelia`'s password in LLDAP, the executor needs a directory credential. Would that be + a dedicated LLDAP account (no narrower group than `lldap_password_manager` exists) delivered as a + cataloged credential? Or do you see another lane shape? + +## railiance-platform + +1. A Kubernetes auth role for the executor's ServiceAccount in `sso`, with policies limited to the paths + above (as in CCR-2026-0052..0054). Which CCR request types: `workload-kv-read` for the journey + secrets (NK-WP-0056-T10), and a new KV-write-next-version type for the rotation? +2. Receipt sender: per NK-WP-0040-T02, you register senders for audit-core. Can the executor pod receive + an ESO-projected sender bearer like other in-cluster senders? + +## audit-core + +1. Will you hold the executor's execution-attribution receipts (Playbook Capability Contract v0.2, + NK-WP-0040) as audit events from a registered in-cluster sender? +2. The receipt adds per-step outcomes, check results, revert yes/no and budget used, and binds the + admission id, admission digest and approval reference in `decision_refs`. Does that fit your event + model, or should these be separate events correlated by `run_id`? + +## glas-harness + +1. GLAS-WP-0018 (session contract): when could a harness-launched agent present as `AGENT` with a + verifiable "harness-launched" assertion? The standard's BEA-4 requires it for agent executors. +2. Not needed for the pilot. This asks whether glas-harness wants to own the agent-executor path later. + +## railiance-apps + +1. The executor needs a deployment package under ADR-0015 (working name `rapp-bounded-executor`): + an image built by Forgejo, and a Deployment or Job in `sso` with its own ServiceAccount. Who + creates the repository, and which conventions apply? diff --git a/workplans/NK-WP-0056-bounded-executor-path.md b/workplans/NK-WP-0056-bounded-executor-path.md index 68784a5..8dd84e6 100644 --- a/workplans/NK-WP-0056-bounded-executor-path.md +++ b/workplans/NK-WP-0056-bounded-executor-path.md @@ -85,10 +85,11 @@ privacyIDEA-cache finding; recurring admissions are excluded from v0.1. The Appr ```task id: NK-WP-0056-T02 -status: todo +status: wait priority: high assignee: claude-code needs_human: true +decision_id: 6d1adce9-40e2-472a-92bb-0ae942218ae8 intervention_note: "Founder chooses the executor runtime owner; owner answers are agreements, not agent decisions." depends_on: [NK-WP-0056-T01] state_hub_task_id: "7263417b-b227-54f7-9edc-3e7f97cf132f" @@ -104,6 +105,13 @@ itself. **Done when:** each component has a named owner and an answer, and the founder has chosen the executor runtime owner. +**2026-10-31, founder decision (hub `6d1adce9`): net-kingdom writes the executor runtime** (source and tests next +to the admission validator, bind lanes and synthetic journey); a new `rapp-*` package (working name +`rapp-bounded-executor`, ADR-0015) builds and deploys it in `sso`; glas-harness is the later path for agent +executors. Owner requests sent the same day through the hub to approval-engine, access-engine, secrets-engine, +railiance-platform, audit-core, glas-harness and railiance-apps +([requests and answer table](../docs/proposals/2026-10-31-nk56-t02-owner-requests.md)). Waiting on their answers. + ## Executor identity and authority ceiling ```task