Skip to main content
Rotacja zastępuje klucz wysyłania projektu. Nie zmienia projektu ani zapisanej w nim telemetrii. Do zarządzania kluczami używaj uwierzytelnienia konta. Klucz wysyłania może tylko wysyłać telemetrię. Nie może zarządzać kluczami. Zanim zaczniesz, zainstaluj CLI i zaloguj się. Ustaw LOGBREW_PROJECT_ID na UUID projektu. Ustaw LOGBREW_API_URL na https://api.logbrew.co. Przykłady używają powłoki Bash, curl 7.76.0 lub nowszego i jq. Przy planowanej rotacji utwórz, wdróż i przetestuj nowy klucz, zanim unieważnisz stary. Częstotliwość rotacji ustal w swojej polityce bezpieczeństwa. Jeśli klucz ma datę wygaśnięcia, wymień go przed tą datą.
Ujawniony klucz to incydent bezpieczeństwa. Unieważnij go natychmiast, nawet zanim wdrożysz nowy klucz. Aplikacje, które nadal używają unieważnionego klucza, nie mogą wysyłać telemetrii.
1

Utwórz nowy klucz

POST /api/projects/{project_id}/ingest-keys przyjmuje niepusty label o długości do 120 znaków. kind ma wartość cli, sdk, browser, server lub artifact. Klucz artifact nie może wysyłać telemetrii. Opcjonalne expires_at musi być czasem RFC3339 z przyszłości.Użyj tego samego kind co stary klucz. Gdy pominiesz --kind, CLI używa sdk, a gdy pominiesz --label – CLI-created SDK key. CLI nie ma flagi daty wygaśnięcia. Aby ustawić expires_at, użyj API.CLI zapisuje jednorazowy token do nowego pliku dostępnego tylko dla właściciela, poza systemem kontroli wersji. Wypisuje metadane, a nie token:
Kontynuuj dopiero wtedy, gdy polecenie się powiedzie. Ustaw NEW_KEY_ID na zwrócone ingest_key.id.Jeśli wynik jest niepewny, uruchom dokładnie to samo polecenie ponownie. CLI użyje ponownie swojego oczekującego klucza ponowienia. Nie używaj --abandon-retry przy tym ponowieniu.Klient, który wywołuje API bezpośrednio, dostaje token raz, w odpowiedzi. Aby ponowić żądanie, wyślij ten sam nagłówek Idempotency-Key z tą samą treścią. Przez 24 godziny takie ponowienie zwraca ten sam klucz. Nigdy nie wypisuj tokena, nie commituj go i nie udostępniaj.
2

Wdróż nowy klucz, gdy stary jest nadal aktywny

Umieść nowy token w chronionym ustawieniu wdrożenia. Wdróż aplikację. Pozostaw stary klucz aktywny. Nie umieszczaj żadnego z tokenów w kodzie źródłowym, wynikach builda ani logach.
3

Wyślij jedno syntetyczne zdarzenie

Załaduj nowy token do zmiennej powłoki new_ingest_key. Nie wypisuj go. Wyślij jeden syntetyczny log z nowym kluczem, a potem go odczytaj:
Kontynuuj dopiero wtedy, gdy odczyt zwróci ten log z tym samym occurred_at. Starszy log ze sprawdzenia rotacji nie dowodzi, że nowy klucz działa. Potwierdź też, że wdrożona aplikacja wysyła telemetrię. Jeśli polecenie się nie powiedzie, zatrzymaj się i przeczytaj odpowiedź. Pozostaw stary klucz aktywny, chyba że został ujawniony.
4

Wyświetl metadane kluczy bez sekretów

Ustaw LOGBREW_ACCOUNT_BEARER na podstawie uwierzytelnienia konta. Znajdź ID starego klucza. Potwierdź, że NEW_KEY_ID ma status active:
Odpowiedź to tablica metadanych kluczy bez tokenów. Status ma wartość active, expired lub revoked. Klucz ma status expired, gdy minął jego czas expires_at.
5

Unieważnij tylko stary klucz

Ustaw OLD_KEY_ID na podstawie listy. Polecenie unieważnia stary klucz tylko wtedy, gdy oba ID są różne:
DELETE jest idempotentne. Zwraca metadane klucza z status: "revoked" i ustawionym revoked_at. Po niepewnej odpowiedzi możesz je bezpiecznie powtórzyć.Uruchom unset new_ingest_key. Z plikiem klucza postępuj zgodnie ze swoją polityką dotyczącą sekretów.

Bezpiecznie napraw błędy

Jeśli rotacja nadal się nie udaje, zgłoś problem. Udostępnij tylko metadane klucza. Nie dołączaj poświadczeń, nagłówków, surowej telemetrii, danych klientów, lokalnych ścieżek ani kodu źródłowego.