NK-WP-0058: route owner decisions; E3 and C3 already answered by their owners; NK-WP-0057-T01 gets E5/C7, E2, E7
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 943911@bnt-lap001 Assistant-Session: fc322940-1c8e-4bed-ab39-86cec99f23a0
This commit is contained in:
parent
e1561c09ee
commit
7cf210e126
2 changed files with 35 additions and 11 deletions
|
|
@ -96,12 +96,14 @@ Two facts frame this column:
|
|||
- `principal_type` is human;
|
||||
- the assurance is aal2;
|
||||
- the subject is not the executor itself.
|
||||
- approval-engine also has `required_assurance`. The executor doesn't send it, and checks aal2 itself
|
||||
("recorded, not enforced").
|
||||
- **Proposal:**
|
||||
- `approval_entry` names the failed field: subject, principal type or assurance. That alone would have replaced
|
||||
diagnostic pod 4.
|
||||
- Whether to send `required_assurance` is a question for approval-engine, not a local change.
|
||||
- the deployed approval-engine records assurance but doesn't enforce it, so the executor checks aal2 itself.
|
||||
- **Proposal:** `approval_entry` names the failed field: subject, principal type or assurance. That alone would
|
||||
have replaced diagnostic pod 4.
|
||||
- **Already answered by the owner:** approval-engine replied on 2026-10-31 (message `756016f9`,
|
||||
`docs/decision-services-alignment-answer.md`, `e9e9f93`). `required_assurance` is in source as schema v7: entries
|
||||
below the floor are refused with 403, the claim with `assurance_unsatisfied`, and consume with 409. It waits for a
|
||||
v7 image release and a founder-run rollout with a pre-v7 backup. The executor keeps its own aal2 check until then,
|
||||
and sends `required_assurance` once v7 is live. This is a dependency, not an open decision.
|
||||
|
||||
### E4: informed-decision intake
|
||||
|
||||
|
|
@ -220,7 +222,7 @@ resolve through the rapp config and must equal the routing recipient for the mem
|
|||
- E5: who owns the approver and routing;
|
||||
- E2: KeyCape client registration with no KeyCape rapp;
|
||||
- E7: the LLDAP, Authelia and KeyCape runtime owner in `sso`;
|
||||
- E3: whether approval-engine should enforce `required_assurance`.
|
||||
- E3 is not open: approval-engine enforces `required_assurance` from v7, which waits for its release.
|
||||
- **Transparency findings for T03:**
|
||||
- `executor-lanes.py` lane errors without a cause;
|
||||
- `approval_entry` without the failed field.
|
||||
|
|
@ -234,7 +236,7 @@ NK-WP-0058-T09, as of 2026-11-05. It uses the same revisions as part 1, plus acc
|
|||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| C1 | CCR lifecycle ↔ net-kingdom lane tooling | railiance-platform: `credential-change-requests/CCR-2026-0058`, `-0059`, `scripts/credential-change.py` | `tools/service-binds/executor-lanes.py`, which imports three platform helper modules; `pilot-run.sh` | Local: `tests/test_executor_lanes.py` copies `railiance-platform/scripts` | `window-close` failed as bare `LaneError` (identity phase) | **merge**; **owner decision** on a supported interface |
|
||||
| C2 | Case-type bytes ↔ broker admission | net-kingdom `security-case-types/*/type.yaml` (canon). Pin: railiance-platform `scripts/keycape_client_secret_generate.py ACKNOWLEDGED_TYPES` (sha256) | railiance-platform credential broker | none in net-kingdom. The README errata warns against edits | none (both hashes match today) | **keep**; add a net-kingdom guard test |
|
||||
| C3 | Case status ↔ broker gate | net-kingdom `security-cases/*.yaml` (`status`, `acceptance`); canon `canon/standards/security-case-types_v0.1.md` | broker (`case_not_materialized`), founder runbooks | Local: the broker case check on a synthetic copy | none. The status is committed by hand from a founder message | **keep**; small **owner decision** on who materializes |
|
||||
| C3 | Case status ↔ broker gate | net-kingdom `security-cases/*.yaml` (`status`, `acceptance`); canon `canon/standards/security-case-types_v0.1.md` | broker (`case_not_materialized`), founder runbooks | Local: the broker case check on a synthetic copy | none. The status is committed by hand from a founder message | **keep** (who materializes: tracked in MASON-WP-0010-T03) |
|
||||
| C4 | KeyCape client secret delivery | railiance-platform: CCR-2026-0060 and -0061, `manifests/nk-bind-executor-eso.yaml`, template `keycape-issuer-eso.yaml` | net-kingdom `sso-mfa/k8s/keycape/deployment.yaml` env `KEYCAPE_NK_BIND_EXECUTOR_APPROVAL_CLIENT_SECRET`; `keycape-client.py env_secret_name()`; executor E1 lane | railiance-platform `tests/test_nk_bind_executor_custody.py`, `test_keycape_client_secret_generate.py`; net-kingdom `sso-mfa/k8s/keycape/test_keycape_client.py`; no cross test | none (custody verify passed 2026-11-04) | **merge** |
|
||||
| C5 | audit-core sender bearer custody | railiance-platform: CCR-2026-0063 (path `platform/workloads/net-kingdom/bounded-executor/audit-sender`, field `AUDIT_TOKEN`), ESO to `sso/bounded-executor-tokens` key `audit-core`. Seed: audit-core `scripts/seed-nk-bounded-executor-sender.py` (single seeder) | rapp `templates/job.yaml` mount; executor `audit_core.token_file`; railiance-platform `nk_bind_executor_custody.py verify` | audit-core `tests/test_seed_nk_bounded_executor_sender.py`; railiance-platform custody tests; no cross test | While being prepared: competing seeders in two repos and two Secret names. Settled in RPF-WP-0069 and AUDIT-WP-0018-T04; one stale copy remains | **merge**; **delete** the stale design text |
|
||||
| C6 | Executor's submitter profile | **Two owners, one fact.** informed-decision `deploy/lifecycle/intake-submitters.json` and access-engine `examples/informed-decision-present-existing-review/policy.md present_existing_profiles` (v14) | informed-decision intake; access-engine decisions; executor `executor_identity` (rapp config) | none across the three | none | **merge**; **owner decision** on which is the source |
|
||||
|
|
@ -274,8 +276,10 @@ NK-WP-0058-T09, as of 2026-11-05. It uses the same revisions as part 1, plus acc
|
|||
- **Gap:**
|
||||
- the status is committed by hand by claude-code after the founder reports steps 0–3. No receipt links them;
|
||||
the T04 state file could record that link.
|
||||
- the canon names ops-mason as the materializer, but railiance-platform's go-live steps did it here. Small
|
||||
**owner decision:** amend the canon, or route materialization through ops-mason.
|
||||
- the canon names ops-mason as the materializer, but railiance-platform's go-live steps did it here by hand.
|
||||
That isn't a new question: ops-mason's case build path (`ops-mason build --case`, MASON-WP-0010-T03) exists and
|
||||
waits on railiance-platform's structural evidence. ops-mason reviewed and test-rendered this case on
|
||||
2026-10-31 (message `91e2205f`). Tracked there; no new routing.
|
||||
|
||||
### C4: KeyCape client secret delivery
|
||||
|
||||
|
|
@ -346,7 +350,6 @@ access-engine's policy is the source, with the other checked against it. Until t
|
|||
(an owner request).
|
||||
- **owner decision:**
|
||||
- C1: a supported platform interface for window roles (railiance-platform);
|
||||
- C3, small: who materializes. The canon names ops-mason; railiance-platform did it here;
|
||||
- C6: the source of the submitter profile (informed-decision and access-engine);
|
||||
- C7: routing and visibility (NK-WP-0057, together with E5).
|
||||
- **For T07:** the hard-coded path and cluster UID in audit-core's seeder.
|
||||
|
|
|
|||
|
|
@ -89,6 +89,27 @@ Cover at least:
|
|||
For the bounded-execution path, start from the NK-WP-0058 contract table (NK-WP-0058-T01, T09, T10) instead of
|
||||
inventorying it again. Its rows marked "needs an owner decision" are inputs here.
|
||||
|
||||
**Inputs routed from NK-WP-0058 (2026-11-05).** All are in `docs/bounded-execution-contract-table.md`:
|
||||
|
||||
- **E5 + C7, approver and routing.** The approver is defined in four places: the admission's `approvers`, the
|
||||
rapp's `approver_subjects`, informed-decision's `review-groups.json`, and KeyCape's `sub` format. Nothing checks
|
||||
that they agree. access-engine policy v14 lists a memo only to its `review_recipient`, so informed-decision's
|
||||
routing table decides who can approve, without the admission seeing it. This cost the 2026-11-04 window. The
|
||||
interim check is NK-WP-0058-T03.
|
||||
- **E2, KeyCape client registration.** ADR-0015 moves runtime packages to `rapp-*`, but there is no KeyCape rapp,
|
||||
so client registration (env binding and `keycape-client.py apply`) runs from net-kingdom's reference manifests.
|
||||
Who owns it: net-kingdom, key-cape, or a new rapp?
|
||||
- **E7, `sso` runtime owners.** `docs/responsibility-map.md` names no runtime owner for LLDAP, Authelia or KeyCape
|
||||
in `sso`. SCOPE calls `sso-mfa/k8s/` "migration inputs, not blanket authority".
|
||||
|
||||
Routed to their owners instead (NK-WP-0058 records the message ids):
|
||||
|
||||
- C1 and O1 to railiance-platform;
|
||||
- O2 to ops-warden;
|
||||
- C6 to informed-decision and access-engine.
|
||||
|
||||
E3 was already answered by approval-engine on 2026-10-31. C3 is tracked in ops-mason MASON-WP-0010-T03.
|
||||
|
||||
**Done when:** an inventory table with sources, and the list of routing points in use today (file, owner, what it
|
||||
decides), is in `docs/proposals/`.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue