GloriousFlywheel Dashboard Read Data Policy 2026-04-16

GloriousFlywheel Dashboard Read Data Policy 2026-04-16

Snapshot date: 2026-04-16

Purpose

Capture the first explicit read-side data classification for #172.

The earlier auth work established identity precedence and write-side role checks. This note records the next step: not all authenticated reads should be treated as equal.

Companion notes:

Current Executed Tiers

Tier 0: Public

Current public API surface:

  • /api/health

Reason:

  • health checks need to work without a user session

Tier 1: Authenticated Viewer-Plus

Current authenticated read surfaces:

  • runner inventory
  • runner detail
  • monitoring metrics
  • cache health
  • Kubernetes pod and HPA status
  • event stream

Reason:

  • these are operational visibility surfaces
  • they still require identity now, but they do not expose desired-state config directly

Tier 2: Operator-Plus

Current restricted read surfaces:

  • GitOps config detail
  • GitOps drift detail

Reason:

  • these routes expose desired-state configuration and drift context that is closer to mutation authority than ordinary monitoring

Tier 3: Admin-Only

Current admin-only read surfaces:

  • runtime auth-policy summary in Settings
  • passkey inventory across users
  • auth event history for interactive session and passkey lifecycle actions
  • control event history for compatibility mutations

Reason:

  • these surfaces expose security-governance data rather than ordinary platform monitoring
  • they include policy shape, credential inventory, security-sensitive auth activity, and compatibility mutation history

Why This Split Is Defensible

Before this slice, the dashboard effectively had two buckets only:

  • public health
  • everything else hidden behind ad hoc auth assumptions

That was too coarse once the repo started treating proxy identity, mutation capability, and admin scope more seriously.

Current Recommendation

Keep this tiering until the repo has a stronger control redesign.

In particular:

  1. keep monitoring readable to any authenticated viewer
  2. keep config and drift aligned with operator mutation scope
  3. keep auth-policy introspection, passkey inventory, auth event history, and control event history admin-only
  4. avoid inventing more admin-only surfaces until they have a concrete owner

Remaining Gap

This is still an early policy.

The repo does not yet distinguish:

  • which monitoring surfaces might later become operator-only
  • which admin actions should exist beyond viewing auth-policy shape
  • whether multi-org enrollment and future mutation authority should introduce org-scoped roles beyond viewer / operator / admin

Exit Condition

  • the repo has an explicit read-data classification instead of a flat authenticated/not-authenticated split
  • config and drift visibility matches the current operator-capable mutation tier
  • the next auth step can focus on real admin capabilities instead of baseline route protection

GloriousFlywheel