Wymaganie mówiło o restarcie „WSZYSTKICH TRZECH usług" przy zmianie INTERNAL_TOKEN.
Sprawdzenie żywych deploymentów pokazuje, że token czytają CZTERY: data, logic,
presentation ORAZ render (doszedł przy PRE-24, a wymaganie tego nie nadgoniło).
Kto zrobiłby rotację literalnie, zostawiłby render ze starym tokenem i usługa po
cichu przestałaby się dogadywać — dokładnie ta awaria, przed którą wymaganie
ostrzega. Treść w arkuszu poprawiona.
docs/log33-sekrety-i-rotacja.md:
- MACIERZ zależności wyliczona z deploymentów, nie z założeń. Wniosek praktyczny:
klucze łącz rotuje się PARAMI usług (logic+data, presentation+logic,
presentation+render), a nie całą czwórką — restartu wszystkiego wymaga tylko
INTERNAL_TOKEN.
- Procedury per sekret, od najbezpieczniejszej do przećwiczenia (klucze LLM —
dotykają tylko logiki, awaria widoczna i nieszkodliwa) po INTERNAL_TOKEN.
Wszystkie zachowują pozostałe klucze przez odczyt z istniejącego sekretu —
inaczej rotacja jednego skasowałaby resztę.
- Weryfikacja: sam „Running" NIE wystarcza (pody wstaną, nawet gdy warstwy się nie
dogadują) — trzeba przeliczyć horoskop i wygenerować PDF, żeby dotknąć wszystkich
łącz.
- Kroki hartowania z jasnym podziałem: co zrobione (automount tokenów — deploy #13),
co wymaga węzła (szyfrowanie at-rest), co świadomie odłożone (Sealed Secrets —
dziś sekrety NIE są w repo GitOps, więc ta zasada już jest spełniona; Sealed
Secrets dodałyby odtwarzalność kosztem nowego pojedynczego punktu awarii).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
