docs(bezpieczeństwo): runbook zamknięcia dostępu do baz na NFS (DAN-25) #57

Merged

gitea merged 2 commits from docs/dan25-runbook-nfs into master 2026-08-04 14:43:12 +00:00

Conversation 0 Commits 2 Files Changed 2

+195

gitea commented 2026-08-04 13:54:34 +00:00

Owner

Copy Link

Copy Source

Runbook do wykonania na NAS-ie — krok po kroku, komenda po komendzie.

Bazy leżą na 192.168.1.34:/mnt/Tank1/astrololo, osiągalnym z całej sieci. To
najkrótsza droga do wycieku: omija logowanie, limity, audyt i canary. Cel:
udział widoczny tylko dla trzech węzłów k3s, tylko do odczytu, z root_squash.

Struktura

Faza 0 rozpoznanie → Faza 1 dowód dziury (montowanie z maszyny spoza klastra,
robione PRZED zmianą) → Faza 2 kopia konfiguracji → Faza 3 zmiana (jedna komenda
midclt) → Faza 4 cztery testy (spoza klastra ma odmówić / z węzła ma działać /
aplikacja żyje / reszta homelabu nietknięta) → Faza 5 wycofanie.

Dwie zasady, które wynikły z rozpoznania

Ustaliłem z klastra i pamięci, że Tank1 obsługuje cały homelab: Proxmox
(proxmox-NFS), conjurer (conjurer_swap — z zapisem), media, LXC-e, stacja
robocza. Stąd:

1. Ruszamy wyłącznie udział astrololo, nigdy globalnych ustawień usługi NFS —
   inaczej padną VM-y, bot i biblioteka mediów.
2. W 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 (path vs paths,
hosts, ro, maproot_*) — middleware zmieniało je między wersjami SCALE, więc
nie zgaduję za Ciebie.

Opisane pułapki

• Hookscript Proxmoxa czekający na showmount przed startem VM (zawężamy tylko
  jeden udział, więc przejdzie — ale jest komenda sprawdzająca).
• Po ro: true nie wgrasz już baz przez NFS (świadome; przez GUI/SMB/SSH).
• Lista IP to nie uwierzytelnianie — adres da się podszyć w tej samej sieci.
  Docelowo NFSv4+Kerberos albo wolumen nieosiągalny poza klastrem, jak mówi samo
  wymaganie DAN-25.

Dane w runbooku (węzły .73/.80/.81, konsumenci Tank1) ustalone z żywego
klastra i agentmemory, nie z założeń.

Runbook do wykonania na NAS-ie — krok po kroku, komenda po komendzie. Bazy leżą na `192.168.1.34:/mnt/Tank1/astrololo`, osiągalnym z całej sieci. To **najkrótsza droga do wycieku**: omija logowanie, limity, audyt i canary. Cel: udział widoczny **tylko dla trzech węzłów k3s**, **tylko do odczytu**, z **root_squash**. ## Struktura Faza 0 rozpoznanie → **Faza 1 dowód dziury** (montowanie z maszyny spoza klastra, robione PRZED zmianą) → Faza 2 kopia konfiguracji → Faza 3 zmiana (jedna komenda `midclt`) → **Faza 4 cztery testy** (spoza klastra ma odmówić / z węzła ma działać / aplikacja żyje / reszta homelabu nietknięta) → Faza 5 wycofanie. ## Dwie zasady, które wynikły z rozpoznania Ustaliłem z klastra i pamięci, że **Tank1 obsługuje cały homelab**: Proxmox (`proxmox-NFS`), conjurer (`conjurer_swap` — **z zapisem**), media, LXC-e, stacja robocza. Stąd: 1. **Ruszamy wyłącznie udział astrololo**, nigdy globalnych ustawień usługi NFS — inaczej padną VM-y, bot i biblioteka mediów. 2. **W 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** (`path` vs `paths`, `hosts`, `ro`, `maproot_*`) — middleware zmieniało je między wersjami SCALE, więc nie zgaduję za Ciebie. ## Opisane pułapki - **Hookscript Proxmoxa** czekający na `showmount` przed startem VM (zawężamy tylko jeden udział, więc przejdzie — ale jest komenda sprawdzająca). - Po `ro: true` **nie wgrasz już baz przez NFS** (świadome; przez GUI/SMB/SSH). - **Lista IP to nie uwierzytelnianie** — adres da się podszyć w tej samej sieci. Docelowo NFSv4+Kerberos albo wolumen nieosiągalny poza klastrem, jak mówi samo wymaganie DAN-25. Dane w runbooku (węzły `.73`/`.80`/`.81`, konsumenci Tank1) ustalone z żywego klastra i agentmemory, nie z założeń.

gitea added 2 commits 2026-08-04 13:54:34 +00:00

docs(wymagania): statusy po serii iteracji „czysto" ... 4eacf30883

Aktualizacja kolumny Status wobec stanu faktycznego. Bilans: 62 Zrobione ·
9 W trakcie · 14 Do zrobienia (było 52 · 9 · 24).

Zrobione (zmergowane i działające):
- PRE-03 strefa czasowa z lokalizacji (#43)
- DAN-23 + PRE-10 eksport wyników do Excela (#45)
- PRE-26 cache-busting statyki (#48)
- PRE-06 konfigurowalne aspekty i orby (#49)
- PRE-04 techniki relacyjne — synastria (#51) + Returns w kalendarzu (LOG-12)
- PRE-17 konta imienne i dziennik audytowy (#54)
- PRE-09 + DAN-15 przegląd baz na NFS i ich włączanie/wyłączanie (#55)
- PRE-24 raport PDF — obraz render wreszcie się zbudował, PDF powstaje w produkcji

Świadomie NIE oznaczone jako zrobione:
- LOG-05 / PRE-05 zostają „W trakcie": liczenie kilku systemów domów naraz działa,
  ale egzotyczne (Placidus/Koch/Regiomontanus/Campanus) wymagają silnika swisseph;
- DAN-26 z „Do zrobienia" na „W trakcie": mechanizm rekordów-pułapek jest gotowy
  i przetestowany, ale wstrzyknięcie pułapek do realnych baz i rejestr wariantów
  to krok właściciela, nie kodu.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs(bezpieczeństwo): runbook zamknięcia dostępu do baz na NFS (DAN-25) ... a7910e54c9

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>

gitea merged commit 6e7cfcbbd7 into master 2026-08-04 14:43:12 +00:00

gitea deleted branch docs/dan25-runbook-nfs 2026-08-04 14:43:13 +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#57