tegwick
d961da1ef2
Founder completed paste-once-provision; glas-harness/GLAS-WP-0002-T02's live verification succeeded for real (AppRole login, KV v2 read, real OpenRouter call, real commit, OPENROUTER_API_KEY unset throughout). Two real fixes recorded along the way: platform-admin's policy needed a new reins/* entry (every other KV mount was already listed there), and the consumer policy itself needed the KV v2 data/+metadata/ path shape instead of the bare KV v1 path it was originally written against. Full account in ops-mason/plans/rein-openweights-openrouter-approle.md section 7. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
99 lines
4.4 KiB
Markdown
99 lines
4.4 KiB
Markdown
# rein-openweights AppRole for non-interactive OpenRouter key read
|
|
|
|
Date: 2026-07-27 (promoted to `active` same day, after live verification)
|
|
Catalog: `rein-openweights-openrouter-approle` (status `active`, `resolvable: true`)
|
|
Owner: `ops-mason` (`plans/rein-openweights-openrouter-approle.md`) · consumer: `rein-openweights`
|
|
glas-harness: `GLAS-WP-0002-T02` (the demand this lane unblocks — closed)
|
|
|
|
An OpenRouter API key so `rein-openweights` (the OpenRouter-driven rein in the
|
|
glas-harness family) can authenticate to OpenBao **non-interactively** — no
|
|
operator OIDC session, no human in the loop at run time — the same shape
|
|
`agent-harness-binky-mail-approle` already uses for its own AppRole lane.
|
|
|
|
Deliberately **not** a reuse of the existing `openrouter-llm-connect` lane:
|
|
that lane's `auth_method` is interactive-caller-shaped and its policy is
|
|
shared/high-risk across `activity-core`'s broader usage. This lane is
|
|
narrowly scoped to exactly one path, one consumer — see
|
|
`ops-mason/plans/rein-openweights-openrouter-approle.md` §2 for the full
|
|
reuse-vs-new reasoning.
|
|
|
|
---
|
|
|
|
## OpenBao pointers
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Mount | `reins` (new KV v2 engine, enabled 2026-07-27 — no existing mount fit without widening scope) |
|
|
| Path | `reins/rein-openweights/openrouter` |
|
|
| Field | `api_key` |
|
|
| Policy | `workload-kv-read-rein-openweights-openrouter` (read-only, scoped to exactly this path) |
|
|
| AppRole | `rein-openweights` |
|
|
| `token_ttl` / `token_max_ttl` | `15m` / `30m` (matches `agent-harness-binky-mail`) |
|
|
| `token_num_uses` | `8` (matches `agent-harness-binky-mail` — **not** OpenBao's own default of `0`/unlimited, see build note below) |
|
|
| `secret_id_ttl` | `0` (no expiry, current build-phase posture — same choice `agent-harness-binky-mail` made) |
|
|
| Risk | standard (single provider key, no data-store or infra access; bounded to this one path) |
|
|
|
|
---
|
|
|
|
## Worker checklist
|
|
|
|
For `rein-openweights` itself, non-interactive:
|
|
|
|
1. AppRole login (no operator present):
|
|
|
|
```bash
|
|
ROLE_ID=$(cat ~/.local/rein-openweights/approle/role_id)
|
|
SECRET_ID=$(cat ~/.local/rein-openweights/approle/secret_id)
|
|
TOKEN=$(bao write -field=token auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID")
|
|
```
|
|
|
|
2. Fetch the field (matches `rein_openweights/credentials.py`'s own
|
|
`resolve_openrouter_api_key()` — this is exactly what that code does):
|
|
|
|
```bash
|
|
BAO_TOKEN="$TOKEN" bao kv get -field=api_key reins/rein-openweights/openrouter
|
|
```
|
|
|
|
`rein-openweights`'s own `REIN_OPENWEIGHTS_APPROLE_DIR` env var already
|
|
defaults to the delivery path above; no code change needed to consume this
|
|
lane once the value is provisioned.
|
|
|
|
---
|
|
|
|
## Founder provision (the one place the live value exists outside OpenBao)
|
|
|
|
**Done (2026-07-27)** via `warden desk --act paste_once_provision --path
|
|
reins/rein-openweights/openrouter --field api_key`. Two real issues hit
|
|
along the way, both fixed at the root cause rather than patched around:
|
|
|
|
- `platform-admin`'s own policy had no entry for the new `reins/` mount
|
|
(every other KV mount was already listed there; this one predated the
|
|
fix) — the desk write 403'd until a matching `path "reins/*" {...}`
|
|
block was added.
|
|
- The consumer policy itself (`workload-kv-read-rein-openweights-openrouter`)
|
|
was originally written against the bare KV path — the KV v1 shape,
|
|
which silently denies everything on a v2 mount. Fixed to grant on
|
|
`reins/data/rein-openweights/openrouter` +
|
|
`reins/metadata/rein-openweights/openrouter` instead (see
|
|
`ops-mason/plans/rein-openweights-openrouter-approle.md` §7 for the
|
|
full account, and `ops_mason/executor.py::_policy_hcl` for the code
|
|
fix + regression test).
|
|
|
|
Field verified present (length only, never the value) after the fix.
|
|
`GLAS-WP-0002-T02`'s live verification then succeeded for real: AppRole
|
|
login, KV v2 read, a real OpenRouter API call, a real commit —
|
|
`OPENROUTER_API_KEY` unset throughout, so it was genuinely the vault path
|
|
that ran.
|
|
|
|
## Rotation
|
|
|
|
```bash
|
|
bao write -f auth/approle/role/rein-openweights/secret-id # new secret_id
|
|
# deliver mode-0600 to REIN_OPENWEIGHTS_APPROLE_DIR; shred the old file
|
|
```
|
|
|
|
## See also
|
|
|
|
- `ops-mason/plans/rein-openweights-openrouter-approle.md` — full construction plan, all four phases
|
|
- `ops-mason/INTENT.md` — the builder role this lane was provisioned through
|
|
- `wiki/playbooks/agent-harness-secrets.md#lane-3-mail-approle` — the closest existing analog this lane's shape was mirrored from
|