feat: Add authentication and admin identity to the dashboard UI #60

New issue

Open

opened 2026-04-05 13:41:40 +00:00 by mahmoud · 0 comments

mahmoud commented

2026-04-05 13:41:40 +00:00

Owner

Problem

The hero_compute_ui dashboard (port 9001) has zero authentication. Anyone who can reach the port gets full access to:

Deploy, start, stop, and delete VMs
View all nodes and their stats
Access the Admin panel (stats, logs, configuration)
Use the API Explorer to call any RPC method directly
Open console sessions to running VMs

There is no login, no session management, and no way to distinguish between a node admin, a VM owner, or a random visitor.

What's needed

1. Dashboard authentication

A login mechanism so the UI knows who the visitor is
Session management (cookie/token based)
Unauthenticated visitors should not be able to access any admin functionality

2. Admin identity for nodes

Each node should have a known admin/owner identity
When a node registers with the explorer, it should declare who administers it
The dashboard should verify the logged-in user is the node admin before granting full access

3. Access levels (at minimum)

Node admin — full access: admin panel, configuration, RPC explorer, VM management
VM owner — can manage only their own VMs (already partially supported via the secret capability token)
Viewer / unauthenticated — read-only or no access

Current state

The only identity concept today is the VM-level secret (a capability token per VM for operations like start/stop/delete)
There is no node-level admin identity
The UI serves all pages and proxies all RPC calls without any auth check

Affected crates

hero_compute_ui — needs auth middleware, login flow, session management, role-based route protection
hero_compute_server — needs admin identity on node registration
hero_compute_explorer — needs to store and verify node admin identity

## Problem The hero_compute_ui dashboard (port 9001) has **zero authentication**. Anyone who can reach the port gets full access to: - Deploy, start, stop, and delete VMs - View all nodes and their stats - Access the Admin panel (stats, logs, configuration) - Use the API Explorer to call any RPC method directly - Open console sessions to running VMs There is no login, no session management, and no way to distinguish between a node admin, a VM owner, or a random visitor. ## What's needed ### 1. Dashboard authentication - A login mechanism so the UI knows **who** the visitor is - Session management (cookie/token based) - Unauthenticated visitors should not be able to access any admin functionality ### 2. Admin identity for nodes - Each node should have a known admin/owner identity - When a node registers with the explorer, it should declare who administers it - The dashboard should verify the logged-in user is the node admin before granting full access ### 3. Access levels (at minimum) - **Node admin** — full access: admin panel, configuration, RPC explorer, VM management - **VM owner** — can manage only their own VMs (already partially supported via the `secret` capability token) - **Viewer / unauthenticated** — read-only or no access ## Current state - The only identity concept today is the **VM-level secret** (a capability token per VM for operations like start/stop/delete) - There is no node-level admin identity - The UI serves all pages and proxies all RPC calls without any auth check ## Affected crates - `hero_compute_ui` — needs auth middleware, login flow, session management, role-based route protection - `hero_compute_server` — needs admin identity on node registration - `hero_compute_explorer` — needs to store and verify node admin identity