chore(consistency): renormalize lifecycle state [auto]

Updated by fix-consistency on 2026-06-29:
  - workplan status: ready → active
This commit is contained in:
2026-06-29 17:36:01 +02:00
parent a07f2d3d7f
commit 5c6a3ce95e

View File

@@ -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.