Proposal: Admin console and reporting

ADR-0021 made management API-first and deferred the web UI; ADR-0013/the roadmap reserve it. Operators and tenant admins need a console plus analytics. This specs both as pure clients of the existing admin API (ADR-0021) and telemetry (proposal 0012) — no new backend, no architecture change.

Motivation

API-first is right, but admins expect a console, and a provider needs reporting (login success/failure, MFA adoption, security signals) to operate and to sell. Both are missing.

Design

• A web admin console: tenant / realm / organization / client / user / policy / key management, every operation authorized via Forseti at the caller's scope (delegated administration, proposal 0016). It is a client of the admin API (ADR-0021) — no privileged backdoor.
• Reporting & analytics derived from the observability telemetry and event stream (proposal 0012, ADR-0022): login success/failure, MFA-adoption, active-user, and security/anomaly views — operator-wide, per-tenant, and tenant-facing (proposal 0012).
• No new store: reports are projections of events + OTel metrics. The data comes from proposal 0012's emitted series and the M5 event projections (ADR-0022); this proposal owns presentation only — the emission/presentation split settled in 0012.

Alternatives considered

• API/CLI-only — rejected for adoption; admins expect a console.
• A separate analytics database — rejected: derive from the event stream + telemetry.

Graduation criteria

The console manages all resources via the admin API with delegated-admin scoping; dashboards show login/MFA/security analytics, per-tenant and tenant-facing.

Backward compatibility

A client of the admin API + telemetry; the UI was always API-first-deferred (ADR-0021); no architecture change.

Open questions

• Console technology and hosting; the report set and its retention.