Compare commits

...

3 Commits

Author SHA1 Message Date
gitea 111f11f534 docs(sekrety): dołożenie klucza do ISTNIEJĄCEGO sekretu, nie tylko tworzenie
Po zmergowaniu LOG-34 pody prezentacji nie wstały:
  Error: couldn't find key SESSION_SECRET in Secret astrololo/astrololo-auth

Runbook opisywał wyłącznie ścieżkę instalacji OD ZERA — SESSION_SECRET pojawiał
się tylko w komendzie `create secret`. Na działającym wdrożeniu sekret już
istnieje, a merge manifestu kluczy do niego nie dokłada; każe ich tylko szukać.

Gorzej: opisana rotacja też by tam nie zadziałała. Używała JSON Patch z
`op: replace` na /data/SESSION_SECRET, a `replace` wymaga, żeby ścieżka już
istniała — czyli jedyna komenda, po którą sięgnąłby ktoś w tej sytuacji, też
odmawia.

Teraz obie potrzeby obsługuje JEDNA komenda: `--type=merge` ze `stringData`
dokłada albo nadpisuje i nie wymaga wcześniejszego istnienia klucza. Dopisane
sprawdzenie kompletu kluczy bez pokazywania wartości oraz to samo ostrzeżenie
w runbooku demo, gdzie czeka dokładnie ta sama pułapka.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 12:58:33 +02:00
argocd-image-updater f968eb0340 build: automatic update of astrololo
updates image gitea/astrololo-data tag '71bb3b9c' to 'f0d07ee8'
updates image gitea/astrololo-logic tag '71bb3b9c' to 'f0d07ee8'
updates image gitea/astrololo-presentation tag '71bb3b9c' to 'f0d07ee8'
2026-08-21 10:49:32 +00:00
gitea f754831f54 feat(prezentacja): klucz podpisu sesji (LOG-34)
SESSION_SECRET w sekrecie astrololo-auth. Pod bez niego CELOWO nie wstaje:
usługa z kontami, ale bez klucza, nie odróżniłaby ważnej sesji od podrobionej.

W README dopisana rotacja klucza jako awaryjny wyłącznik — podmiana unieważnia
wszystkie sesje naraz, co jest właściwą reakcją na podejrzenie przechwycenia
cudzej sesji.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 10:47:46 +00:00
3 changed files with 54 additions and 4 deletions
+44 -1
View File
@@ -90,11 +90,54 @@ read -rs -p "Hasło do aplikacji (APP_PASSWORD): " APP_PASSWORD; echo
kubectl -n astrololo create secret generic astrololo-auth \
--from-literal=APP_PASSWORD="$APP_PASSWORD" \
--from-literal=INTERNAL_TOKEN="$(openssl rand -hex 32)"
--from-literal=INTERNAL_TOKEN="$(openssl rand -hex 32)" \
--from-literal=SESSION_SECRET="$(openssl rand -hex 32)"
unset APP_PASSWORD
```
`SESSION_SECRET` podpisuje ciasteczka sesji (LOG-34). **Pod bez niego celowo nie
wstanie**: usługa z kontami, ale bez klucza, nie odróżniłaby ważnej sesji od
podrobionej. Nikt go nigdy nie musi oglądać.
### ⚠️ Masz już sekret sprzed LOG-34? Dołóż klucz, nie twórz od nowa
Komenda wyżej zakłada sekret **od zera**. Jeśli `astrololo-auth` już istnieje,
merge manifestu sam klucza nie dołoży — pod zgłosi wtedy:
```
Error: couldn't find key SESSION_SECRET in Secret astrololo/astrololo-auth
```
Dokładamy klucz, nie ruszając pozostałych:
```bash
kubectl -n astrololo patch secret astrololo-auth --type=merge \
-p "{\"stringData\":{\"SESSION_SECRET\":\"$(openssl rand -hex 32)\"}}"
kubectl -n astrololo rollout restart deploy/presentation
```
Sprawdzenie, że komplet kluczy jest na miejscu (bez pokazywania wartości):
```bash
kubectl -n astrololo get secret astrololo-auth -o jsonpath='{.data}' \
| tr ',' '\n' | grep -o '"[A-Z_]*"'
```
Oczekiwane: `APP_PASSWORD`, `INTERNAL_TOKEN`, `SESSION_SECRET`.
> `--type=merge` ze `stringData` **dokłada albo nadpisuje** i nie wymaga, żeby
> klucz wcześniej istniał — w odróżnieniu od JSON Patch z `op: replace`, który
> na brakującej ścieżce po prostu odmawia. Ta sama komenda służy więc i do
> dołożenia, i do rotacji.
### Rotacja klucza sesji
**Wylogowuje WSZYSTKICH.** To nie usterka, tylko awaryjny wyłącznik: gdy
podejrzewasz, że ktoś przechwycił cudzą sesję, podmiana klucza unieważnia je
wszystkie naraz. Komenda ta sama, co dołożenie wyżej.
`INTERNAL_TOKEN` jest losowany i **nikt go nigdy nie musi oglądać** — służy tylko
usługom do rozmowy między sobą. `APP_PASSWORD` wpisujesz w przeglądarce
(użytkownik: `astrololo`, zmienny przez `APP_USER` w `presentation.yaml`).
+3 -3
View File
@@ -11,10 +11,10 @@ resources:
- ingress.yaml # wejście po https + przekierowanie z http
images:
- name: gitea.czernobog.pl/gitea/astrololo-data
newTag: 71bb3b9c
newTag: f0d07ee8
- name: gitea.czernobog.pl/gitea/astrololo-logic
newTag: 71bb3b9c
newTag: f0d07ee8
- name: gitea.czernobog.pl/gitea/astrololo-render
newTag: latest
- name: gitea.czernobog.pl/gitea/astrololo-presentation
newTag: 71bb3b9c
newTag: f0d07ee8
+7
View File
@@ -32,6 +32,13 @@ spec:
secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
- name: APP_USER
value: "astrololo"
# Klucz podpisu ciasteczek sesji (LOG-34). WYMAGANY — pod bez niego
# celowo nie wstaje: usługa z kontami, ale bez klucza, nie umiałaby
# odróżnić ważnej sesji od podrobionej. Rotacja tego klucza WYLOGOWUJE
# WSZYSTKICH, i tak ma być — to jest awaryjny wyłącznik.
- name: SESSION_SECRET
valueFrom:
secretKeyRef: { name: astrololo-auth, key: SESSION_SECRET }
- name: RATE_LIMIT_PER_MIN
value: "120" # 0 = bez limitu
# Aplikacja stoi za Ingressem, więc bezpośrednim rozmówcą jest zawsze