docs(bezpieczeństwo): runbook rotacji sekretów + poprawka nieaktualnej treści LOG-33 #59

Merged

gitea merged 1 commits from docs/log33-rotacja into master 2026-08-04 15:32:52 +00:00

Conversation 0 Commits 1 Files Changed 2

+171

gitea commented 2026-08-04 15:10:44 +00:00

Owner

Copy Link

Copy Source

⚠️ Znalezisko: wymaganie było nieaktualne

LOG-33 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 wg wymagania, 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:

Sekret	Restart obejmuje
INTERNAL_TOKEN	wszystkie 4, równocześnie
LINK_KEY_*	parę usług (logic+data / presentation+logic / presentation+render)
APP_PASSWORD / APP_USERS	tylko presentation
klucze LLM	tylko logic

Czyli restartu wszystkiego wymaga tylko INTERNAL_TOKEN — klucze łącz rotuje
się parami.

Procedury per sekret, uporządkowane od najbezpieczniejszej do przećwiczenia
(klucze LLM — dotykają tylko logiki, awaria widoczna i nieszkodliwa) po
INTERNAL_TOKEN. Każda zachowuje 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.

Hartowanie z jasnym podziałem: ✅ zrobione (tokeny kont serwisowych — deploy #13),
🔧 wymaga węzła (szyfrowanie at-rest), ⏸️ świadomie odłożone (Sealed Secrets — dziś
sekrety nie są w repo GitOps, więc ta zasada jest już spełniona; Sealed Secrets
dodałyby odtwarzalność kosztem nowego pojedynczego punktu awarii).

## ⚠️ Znalezisko: wymaganie było nieaktualne LOG-33 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 wg wymagania, **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: | Sekret | Restart obejmuje | |---|---| | `INTERNAL_TOKEN` | **wszystkie 4, równocześnie** | | `LINK_KEY_*` | **parę** usług (logic+data / presentation+logic / presentation+render) | | `APP_PASSWORD` / `APP_USERS` | tylko presentation | | klucze LLM | tylko logic | Czyli **restartu wszystkiego wymaga tylko `INTERNAL_TOKEN`** — klucze łącz rotuje się parami. **Procedury per sekret**, uporządkowane od najbezpieczniejszej do przećwiczenia (klucze LLM — dotykają tylko logiki, awaria widoczna i nieszkodliwa) po `INTERNAL_TOKEN`. Każda zachowuje 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. **Hartowanie** z jasnym podziałem: ✅ zrobione (tokeny kont serwisowych — deploy #13), 🔧 wymaga węzła (szyfrowanie at-rest), ⏸️ świadomie odłożone (Sealed Secrets — dziś sekrety **nie są** w repo GitOps, więc ta zasada jest już spełniona; Sealed Secrets dodałyby odtwarzalność kosztem **nowego pojedynczego punktu awarii**).

gitea added 1 commit 2026-08-04 15:10:44 +00:00

docs(bezpieczeństwo): runbook rotacji sekretów + poprawka nieaktualnej treści LOG-33 ... e3114f3e7c

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>

gitea merged commit e3114f3e7c into master 2026-08-04 15:32:52 +00:00

gitea deleted branch docs/log33-rotacja 2026-08-04 15:32:52 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

gitea

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/astrololo#59