LOGBREW_PROJECT_ID auf die UUID des Projekts. Setzen Sie
LOGBREW_API_URL auf https://api.logbrew.co. Die Beispiele nutzen Bash,
curl 7.76.0 oder neuer und jq.
Bei einer geplanten Rotation erstellen, bereitstellen und testen Sie den
Ersatz, bevor Sie den alten Schlüssel widerrufen. Legen Sie das
Rotationsintervall in Ihrer Sicherheitsrichtlinie fest. Wenn ein Schlüssel
ein Ablaufdatum hat, ersetzen Sie ihn vor diesem Datum.
1
Ersatzschlüssel erstellen
POST /api/projects/{project_id}/ingest-keys nimmt ein nicht leeres
label mit bis zu 120 Zeichen an. kind ist cli, sdk, browser,
server oder artifact. Ein artifact-Schlüssel kann keine Telemetrie
senden. Ein optionales expires_at muss eine künftige RFC3339-Zeit sein.Verwenden Sie denselben kind-Wert wie beim alten Schlüssel. Ohne --kind
nutzt die CLI sdk, ohne --label nutzt sie CLI-created SDK key. Die
CLI hat kein Flag für das Ablaufdatum. Um expires_at zu setzen,
verwenden Sie die API.Die CLI speichert das einmalige Token in einer neuen Datei außerhalb der
Versionsverwaltung, die nur Sie lesen können. Sie gibt Metadaten aus,
nicht das Token:NEW_KEY_ID auf die zurückgegebene ingest_key.id.Wenn das Ergebnis unsicher ist, führen Sie genau denselben Befehl noch
einmal aus. Die CLI verwendet ihren ausstehenden Wiederholungsschlüssel
erneut. Verwenden Sie für diese Wiederholung nicht --abandon-retry.Ein direkter API-Client erhält das Token einmal in der Antwort. Für eine
Wiederholung senden Sie denselben Idempotency-Key-Header mit demselben
Body. 24 Stunden lang gibt diese Wiederholung denselben Schlüssel zurück.
Geben Sie das Token nie aus, committen Sie es nie und teilen Sie es nie.2
Neuen Schlüssel bereitstellen, alten Schlüssel aktiv lassen
Legen Sie das neue Token in die geschützte Bereitstellungseinstellung.
Stellen Sie die App bereit. Lassen Sie den alten Schlüssel aktiv. Halten
Sie beide Tokens aus Quellcode, Build-Ausgabe und Logs heraus.
3
Ein synthetisches Ereignis senden
Laden Sie das neue Token in die Shell-Variable Machen Sie erst weiter, wenn das Lesen dieses Log mit demselben
new_ingest_key. Geben
Sie es nicht aus. Senden Sie ein synthetisches Log mit dem neuen
Schlüssel und lesen Sie es dann zurück:occurred_at zurückgibt. Ein älteres Prüf-Log einer früheren Rotation
beweist nicht, dass der neue Schlüssel funktioniert. Bestätigen Sie
außerdem, dass die bereitgestellte App Telemetrie sendet. Wenn ein Befehl
fehlschlägt, halten Sie an und lesen Sie die Antwort. Lassen Sie den
alten Schlüssel aktiv, außer er ist offengelegt.4
Schlüssel-Metadaten ohne Geheimnisse auflisten
Setzen Sie Die Antwort ist ein Array mit Schlüssel-Metadaten ohne Tokens. Der Status
ist
LOGBREW_ACCOUNT_BEARER aus Ihrer Kontoauthentifizierung.
Suchen Sie die ID des alten Schlüssels. Bestätigen Sie, dass
NEW_KEY_ID den Status active hat:active, expired oder revoked. Ein Schlüssel ist expired, wenn
seine Zeit in expires_at vorbei ist.5
Nur den alten Schlüssel widerrufen
Setzen Sie
OLD_KEY_ID aus der Liste. Der Befehl widerruft den alten
Schlüssel nur, wenn sich die beiden IDs unterscheiden:DELETE ist idempotent. Es gibt die Schlüssel-Metadaten mit
status: "revoked" und gesetztem revoked_at zurück. Nach einer
unsicheren Antwort können Sie es gefahrlos wiederholen.Führen Sie unset new_ingest_key aus. Behandeln Sie die Schlüsseldatei
gemäß Ihrer Richtlinie für Geheimnisse.Sicher wiederherstellen
Wenn die Rotation weiter fehlschlägt, nutzen Sie
Problem melden. Teilen Sie nur
Schlüssel-Metadaten. Geben Sie keine Zugangsdaten, Header, rohe Telemetrie,
Kundendaten, lokale Pfade oder Quellcode weiter.
