Skip to main content
La rotazione sostituisce una chiave di ingestione del progetto. Non cambia il progetto né la telemetria salvata. Gestisci le chiavi con l’autenticazione dell’account. Una chiave di ingestione può solo inviare telemetria. Non può gestire le chiavi. Prima di iniziare, installa la CLI ed esegui l’accesso. Imposta LOGBREW_PROJECT_ID sull’UUID del progetto. Imposta LOGBREW_API_URL su https://api.logbrew.co. Gli esempi usano Bash, curl 7.76.0 o successivo e jq. Per una rotazione pianificata, crea la chiave sostitutiva, esegui il deploy e provala prima di revocare quella vecchia. Stabilisci l’intervallo di rotazione nella tua policy di sicurezza. Se una chiave ha una data di scadenza, sostituiscila prima di quella data.
Una chiave esposta è un incidente di sicurezza. Revocala subito, anche prima del deploy della chiave sostitutiva. Le applicazioni che usano ancora una chiave revocata non possono inviare telemetria.
1

Crea la chiave sostitutiva

POST /api/projects/{project_id}/ingest-keys accetta un label non vuoto di massimo 120 caratteri. kind vale cli, sdk, browser, server o artifact. Una chiave artifact non può inviare telemetria. Un expires_at facoltativo deve essere un orario RFC3339 futuro.Usa lo stesso kind della vecchia chiave. La CLI usa sdk quando ometti --kind e CLI-created SDK key quando ometti --label. La CLI non ha un flag per la scadenza. Per impostare expires_at, usa l’API.La CLI salva il token monouso in un nuovo file accessibile solo al proprietario, fuori dal controllo del codice sorgente. Stampa i metadati, non il token:
Continua solo dopo che il comando è riuscito. Imposta NEW_KEY_ID sul valore ingest_key.id restituito.Se il risultato è incerto, esegui di nuovo esattamente lo stesso comando. La CLI riusa la chiave del tentativo in sospeso. Non usare --abandon-retry per questo nuovo tentativo.Un client che chiama direttamente l’API riceve il token una sola volta, nella risposta. Per riprovare, invia lo stesso header Idempotency-Key con lo stesso corpo. Per 24 ore, quel nuovo tentativo restituisce la stessa chiave. Non stampare mai il token, non inserirlo in un commit e non condividerlo.
2

Esegui il deploy della nuova chiave mentre la vecchia resta attiva

Inserisci il nuovo token nell’impostazione di deploy protetta. Esegui il deploy dell’app. Mantieni attiva la vecchia chiave. Tieni entrambi i token fuori dal codice sorgente, dall’output della build e dai log.
3

Invia un evento sintetico

Carica il nuovo token nella variabile di shell new_ingest_key. Non stamparlo. Invia un log sintetico con la nuova chiave, poi rileggilo:
Continua solo quando la lettura restituisce questo log con lo stesso occurred_at. Un log di controllo di una rotazione precedente non dimostra che la nuova chiave funziona. Verifica anche che l’app distribuita invii telemetria. Se un comando non riesce, fermati e leggi la risposta. Mantieni attiva la vecchia chiave, a meno che non sia esposta.
4

Elenca i metadati delle chiavi senza segreti

Imposta LOGBREW_ACCOUNT_BEARER con il valore della tua autenticazione dell’account. Trova l’ID della vecchia chiave. Verifica che NEW_KEY_ID sia active:
La risposta è un array di metadati delle chiavi senza token. Lo stato vale active, expired o revoked. Una chiave è expired quando il suo orario expires_at è passato.
5

Revoca solo la vecchia chiave

Imposta OLD_KEY_ID con l’ID preso dall’elenco. Il comando revoca la vecchia chiave solo quando i due ID sono diversi:
DELETE è idempotente. Restituisce i metadati della chiave con status: "revoked" e revoked_at impostato. Puoi ripeterlo in sicurezza dopo una risposta incerta.Esegui unset new_ingest_key. Gestisci il file della chiave secondo la tua policy sui segreti.

Ripristina in sicurezza

Se la rotazione continua a non riuscire, invia una segnalazione. Condividi solo i metadati delle chiavi. Non includere credenziali, header, telemetria grezza, dati dei clienti, percorsi locali o codice sorgente.