Skip to main content

Servizi privilegiati (Tier 3)

Mai raggiungibili da un workspace. Accettano structured intent dal gateway, mai comandi.

workspace-orchestrator​

Possiede: il ciclo di vita dei workspace dei collaboratori. Il servizio più importante per il modello di isolamento.

Responsabilità:

  • Provisioning di un workspace da un template al momento del claim
  • Montare solo il path autorizzato — isolamento per assenza, non per permesso
  • Configurare il sparse checkout corrispondente all'assegnazione
  • Ibernazione su inattività, distruzione al rilascio
  • Applicare quote di risorse

Note di design:

  • Non costruire questo da zero. Coder (self-hosted) risolve già provisioning, templating, ibernazione e accesso sicuro, con un provider Docker — Terraform in Coder descrive il workspace, non implica VM.
  • La scelta del runtime è il modello di sicurezza. Il Docker semplice condivide il kernel host; Docker + gVisor (runsc) è il punto di equilibrio sensato per collaboratori esterni verificati. VM per collaboratore sono più robuste ma confliggono con il modello "lavora quando vuoi" a meno che l'ibernazione non sia aggressiva.
danger

Il Docker socket non deve mai essere raggiungibile da un workspace. È il percorso di escape più comune e rende ogni altro controllo decorativo.

vcs-service​

Possiede: tutte le operazioni Git e le credenziali GitHub.

Responsabilità:

  • Snapshot del working tree e calcolo dell'hash del contenuto
  • Commit e push per conto di un collaboratore, sotto l'account condiviso
  • Impostare user.name / user.email per collaboratore e aggiungere trailer Contributor: / Task-Id: / Content-Hash:
  • Applicare la branch policy: branch per-task, mai main, nessun force push

Note di design:

  • I collaboratori condividono un account GitHub centrale, quindi l'identità Git non prova nulla. I trailer sono utili per il debug; il ledger di audit è la fonte di verità per l'attribuzione.
  • Il token non entra mai nel workspace. Il collaboratore non lo ha mai visto.

build-service​

Possiede: build delle immagini e le relative credenziali.

Responsabilità:

  • Fresh checkout dall'hash dello snapshot — mai riutilizzare la working directory del collaboratore
  • Build dell'immagine, taggata per utente e branch
  • Push al registry; registrazione del container per il routing
  • Cleanup TTL di container di test e immagini

Note di design:

  • Il Dockerfile è modificabile dal collaboratore e deve essere trattato come input ostile: build rootless, --security-opt=no-new-privileges, nessun mount del socket host, egress filtrato.
  • Effimero è meglio di persistente: spawn, build, termina.
  • Le build concorrenti non devono condividere cache o filesystem temporaneo.

audit-service​

Possiede: il registro append-only di chi ha fatto cosa.

Responsabilità:

  • Log immutabile: attore, azione, target, timestamp, hash del contenuto, esiti dei check, SHA del commit risultante
  • API di query per il profile-service e per la revisione interna
  • Retention allineata con obblighi contrattuali e contabili
danger

Con un account Git condiviso, questo è l'unico registro di attribuzione autorevole nel sistema. Non è un application log — trattalo come un ledger: append-only, nessun aggiornamento, nessuna cancellazione.