docs: propose dashboard RBAC, tenant isolation, and operator views (issue #76)

[flo2517]

What

A design proposal, not an accepted ADR — deliberately left for explicit review before implementation starts, unlike ADR-013/014/015 this session. This one decides who can see which tenant's data, a real security boundary rather than a narrower technical decision. Issue #76 itself says this needs its own design pass before implementation, given its size — this is that pass.

New: docs/control-plane/dashboard-rbac-and-tenant-isolation-proposal.md

Grounding

Built on what already exists rather than inventing new mechanism:

• Authentication is already done (ADR-014): session API keys via wallet-signature login.
• Ownership is already done (Build authenticated user and workload API with tenancy boundaries #12): workloads.owner_id, already scoped correctly by internal/workloadapi's gRPC surface — just never wired into the dashboard's HTTP surface, which reads everything unauthenticated today.
• Operator-view data (queue depth, worker claims, retry counts) already exists as plain columns on workloads (attempt_count, next_attempt_at, worker_id, worker_lease_until) — no new schema needed for that slice.

Proposal summary

• A single users.role column (tenant/operator), not a many-to-many table — deliberately avoids speculative complexity the MVP doesn't need yet.
• A three-tier endpoint classification (public/tenant/operator) covering every existing and planned dashboard endpoint.
• An explicit correction: "validator views" (challenge queue, evidence, score history) are public data, not a fourth role — Network Validators authenticate to the Agent (mTLS) and the chain (extrinsic signing) directly, never to the dashboard.
• controlplane-admin grant-role mirroring the existing break-glass operator-tool pattern (create-user/issue-key).
• A requireRole middleware wrapping routes at registration — the whole authorization surface auditable in one function, not scattered per-handler checks.
• A first-pass secret-redaction table that flags workload definition's env vars as the one real leakage risk, needing an explicit redaction decision before tenant workload views can ship (not an oversight to catch later).
• Three open questions listed explicitly for the accepting reviewer, instead of silently guessed at.
• A 6-slice implementation sequence mirroring ADR-013's slicing discipline (schema+grant path → tenant views → overview breaking change → operator queue/worker views → audit log → E2E tests).

Testing

Docs-only change, no code. Cleanly based on current main (no dependency on the still-unmerged #89).

This leaves #76 open: RBAC implementation itself, user/operator views, the secret-redaction decision, and E2E tests are all still outstanding — this document unblocks them, it doesn't build them.

🤖 Generated with Claude Code