Commit Graph

1 Commits

Author SHA1 Message Date
gitea 6e7cfcbbd7 docs(bezpieczeństwo): runbook zamknięcia dostępu do baz na NFS (DAN-25)
build / build (push) Successful in 19s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m29s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m28s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m28s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 14s
Testy / Kontrola składni wszystkich warstw (push) Successful in 11s
Bazy leżą na udziale osiągalnym z całej sieci — to najkrótsza droga do wycieku,
z pominięciem logowania, limitów, audytu i canary. Runbook zawęża udział
`astrololo` do trzech węzłów k3s, ustawia tylko odczyt i root_squash.

Krok po kroku, komenda po komendzie: rozpoznanie → dowód dziury (montowanie
z maszyny spoza klastra) → kopia konfiguracji → zmiana → cztery testy weryfikacyjne
→ ścieżka wycofania.

Dwie zasady wynikające z tego, że Tank1 obsługuje CAŁY homelab (Proxmox, conjurer
z zapisem, media, LXC-e, stacja robocza):
- ruszamy WYŁĄCZNIE udział astrololo, nigdy globalnych ustawień usługi NFS —
  inaczej padną VM-y, bot i biblioteka mediów;
- w TrueNAS SCALE nie edytuje się /etc/exports ręcznie (middleware nadpisze) —
  wszystko przez midclt albo GUI.

Runbook każe też sprawdzić nazwy pól w API PRZED zapisem, bo middleware zmieniało
je między wersjami SCALE (path vs paths).

Opisane pułapki: hookscript Proxmoxa czekający na showmount przed startem VM;
utrata możliwości wgrywania baz przez NFS po ro=true; lista IP to nie
uwierzytelnianie (docelowo NFSv4+Kerberos, jak mówi samo wymaganie).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-04 14:43:12 +00:00