05.1 — Onboarding Edge (Zero-Touch)

L’Invariante

Un token, zero segreti condivisi. Il provisioning porta solo un token bootstrap monouso; la coppia Ed25519 nasce sul device al primo avvio e la privkey non viaggia mai sulla rete.

Il Contratto

La risoluzione dell’identità gira dentro il processo edge stesso — nessun installer separato: prima le variabili d’ambiente, poi le credenziali persistite, poi il claim bootstrap. Riavviare con credenziali esistenti preserva l’identità; rifare il claim con un nuovo bt_* ruota API key e coppia di chiavi del nodo (la vecchia muore all’istante).

Il Flusso

1. Token — ops emette un token bootstrap bt_* dalla console admin (POST /admin/tenants/:id/bootstrap-tokens), con TTL e monouso.
2. Primo avvio — l’edge legge AXIOM_BOOTSTRAP_TOKEN + AXIOM_SYNC_URL e genera la coppia Ed25519 sul device.
3. Claim — POST /api/v1/bootstrap/claim con token + node_pubkey (+ hw_meta opzionale per audit) → { tenant_id, node_id, api_key, scope: "sync" }.
4. Persistenza — le credenziali finiscono in edge-credentials.json (0600); il token è speso e non riutilizzabile.
5. Sync — il nodo inizia a drenare l’outbox, batch firmati, heartbeat a ogni chiamata.

Esempio di Payload

// POST /api/v1/bootstrap/claim — inviato una sola volta, al primo avvio
{ "token": "bt_<48 hex>",
  "node_pubkey": "<base64 SPKI DER>",          // generata sul device
  "hw_meta": { "hostname": "linea-3", "arch": "x86_64",
               "mac_hash": "sha256…", "cpu_model": "…" } }   // metadati audit self-reported
// → 200 { tenant_id, node_id, api_key, scope: "sync" }

I Fallimenti Noti