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.
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: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 Continua solo quando la lettura restituisce questo log con lo stesso
new_ingest_key. Non
stamparlo. Invia un log sintetico con la nuova chiave, poi rileggilo: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 La risposta è un array di metadati delle chiavi senza token. Lo stato vale
LOGBREW_ACCOUNT_BEARER con il valore della tua autenticazione
dell’account.
Trova l’ID della vecchia chiave. Verifica che NEW_KEY_ID sia active: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.
