railiance-platform/workplans/RPF-WP-0069-bounded-executor-lanes.md
codex 7c43f547ad
All checks were successful
CCR intake gate / gate (push) Successful in 12s
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
State Hub ids written back (RPF-WP-0069 T08, T09)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 5502@bnt-lap001
Assistant-Session: 68b3b02f-5d0f-4e71-8421-796f62e50196
2026-11-01 10:26:01 +01:00

9.3 KiB

id type title domain repo status flavor owner topic_slug created updated related state_hub_workstream_id
RPF-WP-0069 workplan Bounded executor lanes: write-next-version type, journey read and audit sender (NK-WP-0056) financials railiance-platform active implementation claude railiance 2026-10-31 2026-11-01
NK-WP-0056
NK-WP-0040
RPF-WP-0067
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

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)

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

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)

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)

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

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

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

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/<client_id>, 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)

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.