AdminEvents pane auth prerequisite: admin.events.read scope #11

Open
opened 2026-05-23 14:25:28 -07:00 by vh · 2 comments
Owner

Context

Design-brief §5 lists five side panes for ratatoskr's TUI. One of them is the AdminEvents pane, which surfaces Worldtree's /admin/events SSE stream (lifecycle events, persona affect, etc.).

Worldtree-dev confirmed in althing thread 01KSBARG2B8M8C82H6AJGJWX1B (2026-05-23) that /admin/events is auth-gated:

Requires admin.events.read scope (enforced at api.py:3261). Your send-only tier doesn't have it.

Posture

Our current API key (c990f0be) is send-only (agents.call:mimir, agents.call:lofn pending — see issue ratatoskr#???/althing thread 01KSBBHDWVZZP10ENMFMNQ1EHW). It does NOT carry admin.events.read.

Worldtree-dev's recommendation:

For ratatoskr's AdminEvents pane: either get a separate admin-tier key from infra-ops (Vuong's call — admin keys are higher privilege), OR if you want operator-only access to that pane, gate it on a separate key the operator passes via env.

What this issue tracks

The auth prerequisite for shipping the AdminEvents pane. Not the pane implementation itself (that's a separate side-pane issue per design-brief §5).

Resolution paths (operator's call)

  1. Single elevated key: ask infra-ops to mint a separate admin-tier key (key_id distinct from c990f0be); ratatoskr accepts it via a new env-var (RATATOSKR_ADMIN_API_KEY or similar) when the pane is enabled.
  2. Augment existing key: ask infra-ops to add admin.events.read scope to the existing key (c990f0be). Simpler but elevates the privilege of every ratatoskr call.
  3. Don't ship the pane: design-brief §5 lists it but it's deferred-by-design; could stay deferred.

Recommendation: defer the decision until the AdminEvents pane is actually being scheduled. Filing this issue now as a documentation breadcrumb so we don't forget the auth gate when we get there.

Out of scope

  • The pane implementation itself (separate side-pane issue).
  • Any other side panes' auth requirements (Persona, Tools, BifrostState, ServerLog — each has its own auth posture, surface as separate issues if/when needed).

Why now

Worldtree-dev surfaced the gate on 2026-05-23. Filing as a doc-debt fix before it's forgotten.

## Context Design-brief §5 lists five side panes for ratatoskr's TUI. One of them is the **AdminEvents pane**, which surfaces Worldtree's `/admin/events` SSE stream (lifecycle events, persona affect, etc.). Worldtree-dev confirmed in althing thread `01KSBARG2B8M8C82H6AJGJWX1B` (2026-05-23) that `/admin/events` is auth-gated: > Requires `admin.events.read` scope (enforced at `api.py:3261`). Your send-only tier doesn't have it. ## Posture Our current API key (`c990f0be`) is send-only (`agents.call:mimir`, `agents.call:lofn` pending — see issue ratatoskr#???/althing thread `01KSBBHDWVZZP10ENMFMNQ1EHW`). It does NOT carry `admin.events.read`. Worldtree-dev's recommendation: > For ratatoskr's AdminEvents pane: either get a separate admin-tier key from infra-ops (Vuong's call — admin keys are higher privilege), OR if you want operator-only access to that pane, gate it on a separate key the operator passes via env. ## What this issue tracks The auth prerequisite for shipping the AdminEvents pane. Not the pane implementation itself (that's a separate side-pane issue per design-brief §5). ## Resolution paths (operator's call) 1. **Single elevated key**: ask infra-ops to mint a separate admin-tier key (key_id distinct from `c990f0be`); ratatoskr accepts it via a new env-var (`RATATOSKR_ADMIN_API_KEY` or similar) when the pane is enabled. 2. **Augment existing key**: ask infra-ops to add `admin.events.read` scope to the existing key (`c990f0be`). Simpler but elevates the privilege of every ratatoskr call. 3. **Don't ship the pane**: design-brief §5 lists it but it's deferred-by-design; could stay deferred. Recommendation: defer the decision until the AdminEvents pane is actually being scheduled. Filing this issue now as a documentation breadcrumb so we don't forget the auth gate when we get there. ## Out of scope - The pane implementation itself (separate side-pane issue). - Any other side panes' auth requirements (Persona, Tools, BifrostState, ServerLog — each has its own auth posture, surface as separate issues if/when needed). ## Why now Worldtree-dev surfaced the gate on 2026-05-23. Filing as a doc-debt fix before it's forgotten.
vh added the needs-triagedocumentationobservabilitytask labels 2026-05-23 14:25:28 -07:00
Author
Owner

Scope request QUEUED to infra-ops (althing thread 01KVKB16VB9GVHE17ERP0R2B5G, 2026-06-20).

Requested path 1 (least privilege): a SEPARATE admin-tier Heimdall key carrying admin.events.read — distinct key_id from the send-only c990f0be, NOT an augmentation of it. ratatoskr will consume it via a new RATATOSKR_ADMIN_API_KEY env var when the AdminEvents pane is built. infra-ops brokers the Heimdall scope with worldtree-dev.

This clears the auth prerequisite this issue tracks; the pane implementation itself remains a separate side-pane issue (out of scope here).

Scope request **QUEUED** to infra-ops (althing thread `01KVKB16VB9GVHE17ERP0R2B5G`, 2026-06-20). Requested **path 1 (least privilege)**: a SEPARATE admin-tier Heimdall key carrying `admin.events.read` — distinct key_id from the send-only `c990f0be`, NOT an augmentation of it. ratatoskr will consume it via a new `RATATOSKR_ADMIN_API_KEY` env var when the AdminEvents pane is built. infra-ops brokers the Heimdall scope with worldtree-dev. This clears the auth prerequisite this issue tracks; the pane implementation itself remains a separate side-pane issue (out of scope here).
Author
Owner

Auth prerequisite CLEARED (2026-06-20). worldtree-dev minted a least-privilege readonly-admin key (key_id 20bb72ad, user ratatoskr-readonly, personal :8081) granting exactly 7 read scopes incl. admin.events.read — writes denied (POST /admin/keys → 403, verified). Collected via a secure mode-600 drop, stored as RATATOSKR_ADMIN_API_KEY in env.sh (mode 600), independently verified GET /admin/keys → 200 from nh3-dev.

The auth gate this issue tracks is resolved; the AdminEvents pane implementation remains a separate side-pane issue (out of scope here).

**Auth prerequisite CLEARED** (2026-06-20). worldtree-dev minted a least-privilege `readonly-admin` key (key_id `20bb72ad`, user `ratatoskr-readonly`, personal `:8081`) granting exactly 7 read scopes incl. `admin.events.read` — writes denied (POST /admin/keys → 403, verified). Collected via a secure mode-600 drop, stored as `RATATOSKR_ADMIN_API_KEY` in `env.sh` (mode 600), independently verified `GET /admin/keys → 200` from nh3-dev. The auth gate this issue tracks is resolved; the AdminEvents pane implementation remains a separate side-pane issue (out of scope here).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vh/ratatoskr#11