feat: add developer console for sandbox operations with phased auth model

[jwx0925]

Why do you need it?

Today OpenSandbox exposes lifecycle APIs and Swagger docs, but developers/operators still need to manage sandbox resources via APIs.

This causes several problems:

• Low operational efficiency for common tasks (search/create/renew/delete sandboxes)
• Weak governance for multi-user usage (single global API key model)
• No centralized audit view for who changed what
• Higher onboarding barrier for teams that are not API-first

A lightweight Console can improve day-2 operations without changing core runtime behavior.

How could it be?

Build a Developer Console (Web UI) for sandbox lifecycle operations, backed by existing server APIs, with incremental authz/authn hardening.

Scope

Phase 1 (MVP):

• Sandbox list/detail pages
• Create sandbox from image + basic runtime options
• Renew expiration, delete sandbox, get endpoint
• Basic filtering by state/metadata
• Read-only and operator role separation in UI and API

Phase 2 (Production hardening):

• OIDC login + JWT validation in server
• RBAC + resource scoping (team/owner)
• Audit log for mutating operations
• Better operational UX (bulk ops safeguards, failure insights)

API/Auth Design

• Keep existing API Key flow for service-to-service compatibility.
• Add user auth path for Console:
  • Frontend gets user identity from OIDC
  • Server validates JWT and extracts claims (user/team/role)
  • Server enforces authorization for each lifecycle action
• Do not expose server API key to browser clients.

DB Decision

• MVP can start without introducing DB:
  • Reuse sandbox metadata for owner/team tags
  • Use static/config-based role mapping for initial rollout
• Introduce PostgreSQL in Phase 2 when we need durable:
  • RBAC bindings and policy rules
  • Audit trails and queryability
  • Quota/rate-limit/account-level governance

Deliverables

• console/ frontend app (or equivalent module) integrated with lifecycle APIs
• Server auth extension for JWT validation and authz checks
• Audit event model + persistence (Phase 2)
• Docs: deployment guide, auth config guide, operator runbook

Acceptance Criteria

• Developers can complete sandbox lifecycle operations entirely from Console.
• Role boundaries are enforced server-side (not only hidden in UI).
• Existing API-key-based automation remains backward compatible.
• Security baseline: no API key in browser, authenticated writes are auditable.

Other related information

Non-goals (for MVP)

• Full billing/chargeback portal
• Complex approval workflows
• Replacing existing SDK/CLI workflows

Risks

• Scope creep from "simple UI" to full multi-tenant platform
• Auth migration complexity if done in one big-bang release

Suggested implementation strategy

• Ship MVP fast (no DB), validate usage and workflows.
• Add PostgreSQL-backed authz/audit capabilities in next iteration.
• Keep API contracts stable while introducing auth enhancements.

[divyamagrawal06]

Hi @jwx0925 , I can try to take this on, starting at Phase 1 (MVP). Since I am new to the repository, would it be okay if I build this as a standalone react app in a new /console directory?

[jwx0925]

Hi @jwx0925 , I can try to take this on, starting at Phase 1 (MVP). Since I am new to the repository, would it be okay if I build this as a standalone react app in a new /console directory?

Welcome to contribute! I suggest first writing a design proposal following the OSEPs requirements and submitting it for PR review. Once the review is approved, proceed with development according to OSEPs.

[divyamagrawal06]

Thanks for the quick response. Working on the design proposal now.