From 5c6a3ce95e9f970d3d12fbc350ded6e9e73b078a Mon Sep 17 00:00:00 2001 From: tegwick Date: Mon, 29 Jun 2026 17:36:01 +0200 Subject: [PATCH] chore(consistency): renormalize lifecycle state [auto] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Updated by fix-consistency on 2026-06-29: - workplan status: ready → active --- ...lm-connect-openrouter-provider-key-lane.md | 262 ++++++++++++++++++ 1 file changed, 262 insertions(+) create mode 100644 workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md diff --git a/workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md b/workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md new file mode 100644 index 0000000..34e8c9d --- /dev/null +++ b/workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md @@ -0,0 +1,262 @@ +--- +id: RAILIANCE-WP-0010 +type: workplan +title: "llm-connect OpenRouter Provider Key Lane" +domain: financials +repo: railiance-platform +status: active +owner: codex +topic_slug: railiance +planning_priority: high +planning_order: 10 +created: "2026-06-29" +updated: "2026-06-29" +depends_on_workplans: + - RAIL-PL-WP-0002 + - RAILIANCE-WP-0004 + - RAILIANCE-WP-0007 + - RAILIANCE-WP-0008 +related_state_hub_messages: + - "f76d3a9e-a98f-4081-885d-b79d94312699" +related_ccrs: + - CCR-2026-0003 +state_hub_workstream_id: "f364d405-a85d-4b89-b600-1964ab436cad" +--- + +# RAILIANCE-WP-0010 - llm-connect OpenRouter Provider Key Lane + +## Goal + +Promote the draft llm-connect OpenRouter provider-key access lane from a +proposed CCR to a reviewed, least-privilege, verified OpenBao workload KV lane +that the live llm-connect runtime can consume through External Secrets and that +`ops-warden` can reference without holding the provider key. + +This keeps provider credential custody in the shared platform layer while +leaving llm-connect behavior, model routing, and provider-specific runtime +logic with the owning application/service. + +No task in this workplan may paste, commit, log, or send secret values through +Git, State Hub, chat, prompts, shell history, or workplan text. + +## Suggestion Reviewed + +Ops-warden confirmed the whynot-design lane in State Hub message +`f76d3a9e-a98f-4081-885d-b79d94312699` and noted that the OpenRouter/llm-connect +sibling lane remains draft on its side. The repo already has the proposed +non-secret CCR: + +- `credential-change-requests/CCR-2026-0003-llm-connect-openrouter-api-key.yaml` + +The message called the sibling lane `openrouter-llm-connect`; the CCR uses +catalog id `llm-connect-openrouter-api-key`. Resolve that naming with +ops-warden before activation so automated callers have one stable selector. + +## INTENT Fit + +This work belongs in railiance-platform because it provides the dependable +secret custody and delivery substrate for a shared runtime service. It does not +decide which model or provider llm-connect should use. The platform-owned +output is the OpenBao path, read policy, Kubernetes auth role, External Secrets +target, verification evidence, and ops-warden handoff. + +The plan supports these `INTENT.md` principles: + +- secure custody: the provider key stays in OpenBao/operator custody; +- stable interfaces: llm-connect consumes a documented path, field, role, and + External Secrets target; +- operable and observable: activation requires positive and negative checks + plus non-secret audit evidence; +- independently evolvable: the provider key storage and front-door routing can + change without forcing runtime consumers to know internal topology. + +## Proposed Contract + +| Item | Proposed value | +| --- | --- | +| CCR | `CCR-2026-0003` | +| ops-warden catalog id | `llm-connect-openrouter-api-key` pending naming confirmation | +| Tenant/org | `activity-core` | +| Workload/project | `llm-connect` | +| KV mount | `platform` | +| OpenBao CLI path | `platform/workloads/activity-core/llm-connect/llm-connect-provider-secrets` | +| Secret field | `OPENROUTER_API_KEY` | +| Read policy | `workload-kv-read-llm-connect-provider-secrets` | +| Policy file | `openbao/policies/workload-kv-read-llm-connect-provider-secrets.hcl` | +| Auth method | Kubernetes auth | +| Auth role | `llm-connect-provider-secrets-read` | +| Proposed service account | `llm-connect` | +| Proposed namespace | `activity-core` | +| Delivery surface | External Secrets to `llm-connect-provider-secrets` in `activity-core` | +| ops-warden command | `warden access llm-connect-openrouter-api-key --fetch OPENROUTER_API_KEY` | + +## Tasks + +## T01 - Review CCR scope and selector naming + +```task +id: RAILIANCE-WP-0010-T01 +status: todo +priority: high +state_hub_task_id: "307b75a6-a3a8-473b-b171-7379d2848698" +``` + +Review `CCR-2026-0003` with the platform operator and activity-core owner +before any live OpenBao apply. + +Acceptance: + +- The activity-core owner confirms that llm-connect should receive + `OPENROUTER_API_KEY` through this platform lane. +- ops-warden and railiance-platform agree on one stable catalog id/selector, + reconciling `openrouter-llm-connect` with + `llm-connect-openrouter-api-key`. +- Review comments and approval state are recorded in the CCR without secret + values. +- The lane remains clearly platform-owned secret custody, not llm-connect model + routing or provider selection logic. + +## T02 - Confirm Kubernetes auth and External Secrets binding + +```task +id: RAILIANCE-WP-0010-T02 +status: todo +priority: high +state_hub_task_id: "829192f5-4502-44e0-8020-656d74d5282a" +``` + +Confirm the exact Kubernetes service account, namespace, and External Secrets +target that should consume this lane. + +Acceptance: + +- The service account and namespace are confirmed as + `llm-connect`/`activity-core` or the CCR is updated with the approved + alternative. +- The auth role binds only the approved service account and namespace. +- The External Secrets target is confirmed as + `llm-connect-provider-secrets` or updated with the approved alternative. +- No direct human or agent read path is activated unless separately approved. + +## T03 - Apply or confirm least-privilege OpenBao metadata + +```task +id: RAILIANCE-WP-0010-T03 +status: wait +priority: high +state_hub_task_id: "42796ef5-c4a0-45a7-ae41-0ebdeccdb01d" +``` + +Apply the read policy and Kubernetes auth role only after review and binding +confirmation. + +Acceptance: + +- `openbao/policies/workload-kv-read-llm-connect-provider-secrets.hcl` grants + only read access to the exact KV-v2 data and metadata paths. +- The Kubernetes auth role attaches only + `workload-kv-read-llm-connect-provider-secrets`. +- Live apply uses an approved operator path or the delegated applier from + `RAILIANCE-WP-0008`; broad `platform-admin` handoffs are avoided where + possible. +- Apply evidence records only policy name, role name, actor, timestamp, and + non-secret OpenBao request ids. + +## T04 - Provision the provider key through approved custody + +```task +id: RAILIANCE-WP-0010-T04 +status: wait +priority: high +state_hub_task_id: "651f6ec8-b7d6-45e6-9fef-08646ff737c2" +``` + +Have an approved operator create or confirm the OpenBao KV entry and +`OPENROUTER_API_KEY` field. + +Acceptance: + +- The path exists at + `platform/workloads/activity-core/llm-connect/llm-connect-provider-secrets`. +- Field `OPENROUTER_API_KEY` is present. +- The value is entered directly through OpenBao/operator custody, never through + Git, State Hub, chat, prompts, workplans, or shell history. +- Non-secret evidence records only path, field name, actor, timestamp, and + verification result. + +## T05 - Verify positive and negative access + +```task +id: RAILIANCE-WP-0010-T05 +status: wait +priority: high +state_hub_task_id: "d538cfc0-bf68-4889-a5b3-ed94c1679856" +``` + +Prove that the approved llm-connect identity can consume the lane and that +other identities cannot. + +Acceptance: + +- Positive verification shows the approved llm-connect service account can read + `OPENROUTER_API_KEY` through OpenBao or External Secrets without printing the + value. +- Negative verification shows an unapproved service account cannot read the + path. +- OpenBao audit evidence exists for allowed and denied attempts, recorded only + as non-secret request ids or timestamps. +- Verification includes the External Secrets delivery path because that is the + intended production consumer interface. + +## T06 - Activate ops-warden catalog front door + +```task +id: RAILIANCE-WP-0010-T06 +status: wait +priority: medium +state_hub_task_id: "376de3fe-ef9c-4b57-b238-1ba21ac8bb1c" +``` + +Send ops-warden the non-secret pointers needed to promote the agreed +OpenRouter/llm-connect selector from draft to active. + +Acceptance: + +- The handoff includes only catalog id, mount, path, field name, auth role, + policy name/path, External Secrets target, optional flex-auth ref, and + runbook/workplan links. +- ops-warden confirms the catalog entry has no unresolved placeholders. +- ops-warden confirms it proxies access as the caller and holds no provider key + value. +- The CCR front-door readiness becomes active/resolvable only after positive + and negative verification. + +## T07 - Record lifecycle operations + +```task +id: RAILIANCE-WP-0010-T07 +status: wait +priority: medium +state_hub_task_id: "130155a5-e0f9-49f8-ba27-b48098746f02" +``` + +Document how to deactivate, rotate, and respond to compromise for this lane. + +Acceptance: + +- Deactivation disables the ops-warden front door and removes or detaches the + auth role policy without deleting required audit evidence. +- Rotation keeps the provider key inside OpenBao/operator custody and records + only non-secret evidence. +- Compromise response names the immediate front-door disable, provider-key + rotation, and follow-up incident workplan path. + +## Exit Criteria + +- `CCR-2026-0003` is reviewed, approved, applied, verified, and active. +- llm-connect can consume `OPENROUTER_API_KEY` through the approved platform + interface. +- Unauthorized access is denied and recorded. +- ops-warden can resolve the agreed OpenRouter/llm-connect selector without + storing the value. +- No secret values appear in Git, State Hub, chat, prompts, logs, or workplans.