--- id: RPF-WP-0069 type: workplan title: "Bounded executor lanes: write-next-version type, journey read and audit sender (NK-WP-0056)" domain: financials repo: railiance-platform status: active flavor: implementation owner: claude topic_slug: railiance created: "2026-10-31" updated: "2026-11-01" related: - NK-WP-0056 - NK-WP-0040 - RPF-WP-0067 state_hub_workstream_id: "6eb39172-babd-57d1-8a3b-f23c41347c22" --- # RPF-WP-0069 — Bounded executor lanes (NK-WP-0056-T02 owner answer) Receiving workplan for NetKingdom's owner request (State Hub message `9d08288d-e866-4e1c-9c0b-f1cc0968bd4d`; net-kingdom `docs/proposals/2026-10-31-nk56-t02-owner-requests.md`). Owner answer: `docs/credential-lane-designs/bounded-executor.md`. No live, cluster or OpenBao action is part of T01; every CCR stays `proposed` until its approvers act. ## Answer the request and add the write-next-version request type ```task id: RPF-WP-0069-T01 status: done priority: high state_hub_task_id: "27432a77-e111-5aa9-9c23-34fb4c9a2984" ``` Answer doc written; new contract-only request type `workload-kv-write-next-version` (`scripts/workload_kv_write_next_version.py`, `tests/test_workload_kv_write_next_version.py`, dispatch in `scripts/credential-change.py`); CCR-2026-0058 drafted `proposed` with policy artifact `openbao/policies/net-kingdom-bind-executor-svc-authelia-write.hcl`. ## Review CCR-2026-0058 (founder gate) ```task id: RPF-WP-0069-T02 status: done priority: high needs_human: true decision_id: c29c6eda-fa13-4d53-8293-17261eb437c1 blocked_on: human blocking_reason: "Founder approval of CCR-2026-0058 and choice of standing or window-scoped write role (hub decision c29c6eda)" state_hub_task_id: "3d4c818e-0c5f-5a14-9735-8056ff9fc7c3" ``` platform-owner and net-kingdom-owner approve or change CCR-2026-0058. The founder chooses standing or window-scoped write role (recommendation: standing for the pilot). Binding is confirmed only after `sso/nk-bind-executor` exists from the reviewed rapp-* package. ## Attended setup and verification of CCR-2026-0058 ```task id: RPF-WP-0069-T03 status: wait priority: high depends_on: [RPF-WP-0069-T02] state_hub_task_id: "6b456804-c408-53bf-8e1d-49723108fca6" ``` After T02: an attended platform-admin (aal2) session sets `cas_required` on the svc-authelia key, re-checks the coding-agent fence, applies policy and role, and records value-free positive and negative receipts. This needs an owner setup script modelled on net-kingdom `bind-lane.py` setup/verify; write it once approval exists. The founder runs it. ## Journey-secret read lane for the executor (NK-WP-0056-T10) ```task id: RPF-WP-0069-T04 status: done priority: medium state_hub_task_id: "5615be47-2b25-5f7d-a1c2-d4391b1377d0" ``` Draft a `workload-kv-read` CCR (native login, data read only, 15m) for `platform/workloads/net-kingdom/synthetic-journey/syn-journey`, stating that it widens CCR-2026-0057's `runtime_access: false`. Waits for T10 scheduling and the ServiceAccount. **2026-10-31, drafted** at the founder's request (net-kingdom session): - `CCR-2026-0059-net-kingdom-bind-executor-syn-journey-read.yaml` and the policy `openbao/policies/net-kingdom-bind-executor-syn-journey-read.hcl`: read on the data path, plus `lookup-self` and `revoke-self`. - Role `net-kingdom-bind-executor-syn-journey-read`: `sso/nk-bind-executor`, audience `openbao`, 15m, exactly one policy. It is separate from the CCR-2026-0058 write role. - `supersedes_boundary` names the CCR-2026-0057 change. - `lifecycle.role_window` proposes a standing reader (founder decides; window-scoped is the alternative). - `bound_claims_confirmed: false` until the ServiceAccount exists. Validates with only that warning. The pre-existing failures (CCR-2026-0035 and 2 tests) are unrelated. **Done 2026-10-31.** - Approved by the founder (`831a0f9`). The binding was confirmed after the rapp deploy (`b4bafb0`). - The founder ran net-kingdom `tools/service-binds/executor-lanes.py`: - `setup`: the policy and standing role were applied; the CCR-2026-0058 policy and `cas_required` too. - `verify`: exact policy, lease of at most 15m, reads only its path, and the negatives held. - CCR-2026-0059 is `applied`. It becomes `verified` after the first journey run through the role (NK-WP-0056-T10). - Finding: platform-admin has no `patch` on `platform/*`. KV metadata changes therefore use a write that names only the changed field. ## Executor audit-core sender (NK-WP-0040) ```task id: RPF-WP-0069-T05 status: wait priority: medium blocked_on: dependency blocking_reason: "audit-core admits and names the sender (AUDIT-WP-0018-T02)" state_hub_task_id: "5c582aef-ee9d-56ab-a4eb-2019933f00ac" ``` After audit-core admits the sender and names it, draft a `workload-kv-read` CCR in the CCR-2026-0021/0022 shape: custody `platform/workloads/net-kingdom/bounded-executor/audit-sender`, ESO into `sso/nk-bind-executor-audit`, ClusterSecretStore restricted to `sso`. ## LLDAP credential custody for the executor ```task id: RPF-WP-0069-T06 status: cancel priority: medium needs_human: true decision_id: 3d0c8f86-7b9c-456b-8951-5ae889829118 blocked_on: human blocking_reason: "Founder chooses bind self-rotation (no account needed) or a lldap_password_manager account" state_hub_task_id: "1456b467-f7c9-529d-9f3e-39404aaa36c6" ``` After secrets-engine answers the lane shape for the executor's LLDAP credential (its Q2), draft the custody CCR here. ## Founder decisions 2026-10-31 Approved as `ready`. CCR-2026-0058 amended to a window-scoped role (created per admitted run, deleted after the receipt; hub decision c29c6eda) and approved by platform-owner and net-kingdom-owner. T06 is cancelled: the bind rotates its own password (hub decision 3d0c8f86), so the executor needs no LLDAP custody lane. ## Approve tool refuses the second approval for workload-kv-write-next-version ```task id: RPF-WP-0069-T07 status: todo priority: medium state_hub_task_id: "b458e369-73b4-515e-ae01-e8afc0dd35eb" ``` `credential-change.py approve` sets `status: approved` after the first reviewer; for this request type, validation then requires every role approval, so the second `approve` is refused before it can record itself (CCR-2026-0058's net-kingdom-owner approval was recorded by hand in the tool's format). Make validation accept an `approved` request that is still collecting role approvals, or have `approve` set `approved` only once all required roles are present, with a test. ## Broker admits oidc-service-client@0.2 for mint-secret ```task id: RPF-WP-0069-T08 status: done priority: high state_hub_task_id: "ca12e6d4-aac1-56d1-95c0-a0b16a1745a8" ``` Review R1 of `docs/credential-lane-designs/oidc-service-client-review.md`: the create-only grant (CCR-2026-0040/0043) already covers `platform/workloads/keycape/`, but the broker `scripts/keycape_client_secret_generate.py` admitted only `oidc-browser-relying-party@1.1` and required `parameters.client_type == confidential`. The founder acknowledged `oidc-service-client` 0.2 on 2026-11-01 (memo `nk-wp-0056-t14-oidc-service-client-r2`, hub decision `f8044f81`, net-kingdom `9ce0d60`), which meets the RPF-WP-0060-T01 rule. Done 2026-11-01: - `ACKNOWLEDGED_TYPES` pins `oidc-service-client@0.2` (type sha256 `cd238693...`). - `PARAMETER_PINS` is keyed by the exact type reference (`dda3bd19...` for 0.2), so two types sharing a version never share a pin. - Confidentiality is per type (`CONFIDENTIALITY`). Browser 1.1 still requires `client_type: confidential`. For the service type it is derived from the authenticated type bytes: no `client_type` parameter and an unconditional `client-secret-path`. A service case that carries `client_type` is refused (`case_client_type_not_admitted`). - Browser behaviour is unchanged. Create-only is unchanged: an existing path or a lost CAS race exits 3 and is never touched. - Tests (`tests/test_keycape_client_secret_generate.py`, `ServiceClientGenerate`): - the case generates once at the case path; - an existing path is refused; - dry run and a lost CAS race; - confidentiality comes from the type; - before any bao call, everything the pinned validator refuses is refused: the subject prefix, a lifetime over 15m, `openid`, the tenant form, the namespace and ServiceAccount patterns, an `issuer` override, unknown parameters, missing required parameters, and a missing acceptance; - only 0.2 is admitted; - a drifted or proposed type, a wrong parameter pin, and a type that is not confidential by construction all fail closed; - the pins match the source. The first case's custody CCRs (CCR-2026-0060/0061) were checked against the acknowledged 0.2 materialization and now reference it. Activation stays gated on case acceptance, approval and binding confirmation (T09). ## Approve and apply the first service-client case's readers (CCR-2026-0060/0061) ```task id: RPF-WP-0069-T09 status: wait priority: medium state_hub_task_id: "d9838702-3091-5e3c-858f-91208b5537d3" ``` Waits for net-kingdom's acceptance of case `nk-bind-executor-approval` and the attended mint (`keycape-client-secret-generate`, T08). Then: 1. platform-owner (and net-kingdom-owner for 0061) approve; 2. confirm the bindings: `external-secrets/external-secrets` for 0060, `sso/nk-bind-executor` (uid bd15569c) for 0061; 3. the delegated applier or an attended platform-admin applies, with value-free positive and negative receipts.