epic: Cortex as the egress proxy for MOCA's sandbox service (SBX)

Abierto
  • ¿Algo no está bien?
#1,490 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, networking, security

Línea de trabajo

Start with the linked MOCA MI1 §8 contract and §12.3 conformance suite, then review the listed Cortex entry point core/listener/forwardproxy/server.go:963-989 and plugin registration in core/plugins/README.md:60. First settle deployment shape A or B in a design session; the child issues and their named conformance cases define the implementation path. Done means Cortex passes MOCA's conformance suite and verifies the sandbox grant.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement Identity

Goal

Make Cortex the egress proxy for MOCA's sandbox service (SBX): the one place where traffic from code running inside a sandbox leaves for the internet, where each user's real credentials are swapped in, and where Cortex's policy plugins (IBAC, SPARC, OPA, budgets, observability) run on that traffic.

This epic replaces #905. That issue's history (the Z5 per-subject injector, two rescopes, a gap analysis) is summarised here, so the design sessions can start from this page.

Where Cortex would sit

SBX runs every tool call in a fresh Firecracker microVM (ADR-0042, SBX0 design). The VMs have no network device. A guest's HTTPS_PROXY=http://127.0.0.1:3128 is spliced over vsock to a Unix socket per VM on the KVM host. One egress proxy per host is shared by every VM on it, so it serves many users at once.

 guest (curl, pip, git, SDKs)                     KVM host                          internet
 HTTPS_PROXY ─► vsock 1025 ─► per-VM Unix socket ─► egress proxy ─► allow list, SSRF ─► github.com …
                              (fd handed over by     │  identity = the socket the
                               vmpool, SCM_RIGHTS)   │  connection arrived on
                                                     └► (identity, host) → user's credential

Each guest holds only an inert placeholder (moca-placeholder). The proxy overwrites it with the right user's credential for the destination host.

The contract is MOCA MI1 §8, and its black-box test suite is §12.3.

The plan, and why Cortex is not on the critical path

MOCA ships its own small Go proxy, moca-egress, first (rossoctl/moca#583: transport slice, the control protocol, and a public conformance suite at remote-worker/egress/conformance). Cortex replaces it when it passes the same suite and MOCA needs a capability only Cortex has. Each child issue names the conformance case that proves it is done.

Not yet decided: two deployment shapes. These change how much each issue has to cover. Please settle them in the first design session:

  • A. Cortex owns everything. Cortex accepts the per-VM sockets and does identity, the allow list and SSRF checks itself. Every issue below applies.
  • B. MOCA front end, Cortex behind it. A small MOCA component owns the VM sockets, the connection → sandbox binding, the allow list and the SSRF check. It stamps a verified identity onto the plaintext CONNECT. Cortex trusts that identity only on the front end's socket. #1477, #1483 and #1484 move to MOCA, and #1476 shrinks.

Child issues

Priorities: P0 means no per-user injection without it. P1 means needed before any user. P2 means needed before many users. P3 is compatibility.

Issue Pri Gap In #905's breakdown?
#1476 P0 Caller identity from the connection, carried into every bridged request and every plugin step 4
#1477 P0 Per-VM Unix-socket listeners handed over at run time (SCM_RIGHTS), with a control channel step 3 (Unix sockets only)
#1478 P0 Credential keyed by (identity, host), resolved from MOCA's token endpoint step 1
#1479 P0 Inject into the header the credential declares (Bearer, Basic for git, x-api-key), always overwriting new
#1480 P1 Fail closed on hosts that have a credential: never fall back to an opaque tunnel new
#1481 P1 Refuse to send a credential over plain HTTP (403 plaintext_credential) new
#1482 P1 Exactly one audit event per injection, in MOCA's audit shape step 2
#1483 P1 Deny-by-default destination allow list new
#1484 P1 SSRF guard: resolve once, refuse private and metadata ranges, dial the checked address new
#1485 P2 Per-VM connection cap and per-session request cap (429) new
#1486 P2 Session recording and the session API on a shared host new
#1487 P3 Run body-reading plugins (IBAC, SPARC, tool-prune) under a streaming contract new
#1488 P3 WebSocket upgrades on intercepted connections new
#1489 — Verify MOCA's sandbox grant and pass the conformance suite step 5

Suggested order: settle the A/B decision first. Then #1476 → #1478 → #1479, the injection path, which only becomes safe once #1476 lands. Then #1480, #1481 and #1482. #1483–#1488 depend on the A/B decision, and #1489 is the final gate.

Already matching

Nothing needs doing here:

  • An inner Host that differs from the CONNECT authority gets 421 (core/listener/forwardproxy/server.go:963-989).
  • The upstream certificate is verified before a leaf is minted.
  • The plugin model fits. Plugins register in init() behind include_plugin_<name> build tags (core/plugins/README.md:60), so MOCA can link its own identity or resolver plugins into a downstream build without forking.

References

Lenguaje dominante
Go
Estrellas
23
Forks
44
Merge medio
14 h 38 min
PR fusionados (30 d)
254

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rossoctl/cortex

Todos los issues de rossoctl/cortex

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.