Micha/homelab-infra
1
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

docs: record tailscale acl plan and watcher activation

Browse Source
This commit is contained in:
Micha
2026-06-05 23:27:40 +02:00
parent 2f3d184a3b
commit dda6021116
2 changed files with 75 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/MASTER_TODO.md
+3 -2
View File
@@ -41,7 +41,7 @@ Host-/Entscheidungsaufgaben beim **Operator**.
| BitLocker-Entscheidung `baerchen` | C: (und ggf. D:) aktivieren oder bewusst deaktiviert lassen? Bei Ja: Recovery-Key vorher nach `D:\30_Finanzen\...`, Vaultwarden und physisch sichern. (Claude fasst BitLocker bewusst nicht an.) | `docs/SECRETS_MAP.md`, `ops/windows-reinstall/docs/laufwerks-neustruktur-2026-06-04.md` |
| Veeam Storage Encryption `baerchen` | Reicht der erste unverschluesselte Full-Lauf, oder soll Veeam Storage Encryption aktiviert werden? Bei Ja: Passwort in Vaultwarden anlegen, Job umstellen und neues Full-Backup erzeugen | `ops/windows-reinstall/docs/windows-image-backup-baseline.md`, `docs/SECRETS_MAP.md` |
| Stromverbrauch messen | Messgeraet/Smart-Plug beschaffen? Ohne Geraet bleiben Idle/Normal/Backup/Last bewusst offen. **Status 2026-06-05: kein Geraet vorhanden.** | `docs/HARDWARE_INVENTORY.md` Abschnitt "Stromverbrauch" |
| Tailscale ACL-Policy | **Jetzt sicherheitsrelevanter:** Messung 2026-06-05 zeigt, dass der Host das ganze LAN `192.168.178.0/24` als Subnet-Route ins Tailnet bringt — jedes Tailnet-Geraet kann darueber LAN-/Admin-Dienste erreichen. Entscheidung: Default-Allow belassen oder Tag-basierte ACL (`tag:operator`/`tag:family`) einfuehren? Aktuelle Policy read-only aus Admin-Konsole sichten, kein Wert ins Repo | `docs/NETWORK_INVENTORY.md` Abschnitt "Tailscale" / "ACL-Policy" |
| Tailscale ACL-Policy | **Entwurf abgestimmt 2026-06-05, noch nicht angewendet.** Richtung: Tag-basiert (`tag:server`/`tag:operator`/`tag:family`), Allow-all spaeter ersetzen; `baerchen-1`+`iphone-14` = operator, `kallilabcore` = server, Familie nur gezielte Dienste. Heute bewusst nur Sichtung, kein Tagging. **Offen vor Umsetzung:** (1) aktuellen ACL-JSON read-only sichten, (2) konkrete Familien-Dienste/Ports festlegen, (3) lockout-sichere Tagging-Reihenfolge + Smoke-Tests mit Operator durchfuehren | `docs/NETWORK_INVENTORY.md` Abschnitt "ACL-Policy — Entwurf und Rollout-Plan" |
| Nextcloud 2FA / Brute-Force-Haertung | Operator-TOTP (`twofactor_totp`) jetzt aktivieren? Familien-/OIDC-weite Policy separat | `docs/AUDIT_2026-05-25_TODO.md` |
| Authelia Rest-2FA | Weitere Admin-UIs (`monitoring`, `glances`, `glance`, `speedtest`, `pdf`, `mail`, `sp` ...) von `one_factor` auf `two_factor` heben oder bewusst belassen? | `docs/AUDIT_2026-05-25_TODO.md` |
| Authelia OIDC fuer Apps | App-uebergreifendes SSO einfuehren - haengt an Familien-/SSO-Grundsatzentscheidung | `docs/AUDIT_2026-05-25_TODO.md` |
@@ -59,7 +59,7 @@ Bewusst nicht jetzt - mit Review-Trigger.
| Cold-Backup-Rotation | **Bewusst Hetzner-only** (2026-06-05). Keine zweite rotierende Cold-Kopie. Trigger: stark wachsender Datenwert, wiederholte Hetzner-Probleme, geaenderte Praeferenz | `docs/HARDWARE_INVENTORY.md` |
| WAN-Ausfallschutz | **Spaeter evaluieren** (2026-06-05). Mobilfunk-Failover inaktiv; lokale Apps laufen bei WAN-Ausfall weiter. Trigger: haeufigere/laengere DSL-Ausfaelle oder kritischer Remote-Zugang | `docs/NETWORK_INVENTORY.md` |
| Home Assistant InfluxDB Bind | Aktuell `127.0.0.1:8181`, validiert. Nur wenn HA nicht lokal auf den Host schreibt, bewusste Bind-Aenderung planen | `docs/NETWORK_INVENTORY.md` |
| Docker Critical Events Watcher | Aktivierung vorbereitet: `services/posture-check/docker-critical-events-supervisor.sh` kapselt Start/Stop/Status/Smoke fuer das Unraid User Script. Optional spaeter in der Unraid-UI `at array start` aktivieren und ntfy-Smoke fahren; kein Pflicht-Pfad | `docs/SERVICE_CATALOG.md`, `services/posture-check/docker-critical-events.sh`, `services/posture-check/unraid-user-scripts.md` |
| Docker Critical Events Watcher | **Aktiviert 2026-06-05:** Unraid User Script `docker-critical-events-at-start` nutzt den Supervisor und steht in `schedule.json` auf `frequency: start`; Watcher manuell gestartet, Status `running`. Optionaler ntfy-Smoke wurde nachts bewusst nicht gesendet und kann spaeter mit `docker-critical-events-supervisor.sh smoke` nachgeholt werden | `docs/SERVICE_CATALOG.md`, `services/posture-check/docker-critical-events.sh`, `services/posture-check/unraid-user-scripts.md` |
| Negativ-Test Backup-Frische | Quartalsweise: bewusst kaputten/fehlenden Dump in Testpfad simulieren, pruefen ob `homelab-alerts` feuert | `docs/AUDIT_2026-05-25_TODO.md` |
| End-to-end-DR-Drill | Komplett-Bootstrap Phase 1-5 auf Wegwerf-Host; realistisch erst mit zweiter Hardware (siehe auch Extern blockiert) | `docs/AUDIT_2026-05-25_TODO.md`, `docs/DISASTER_RECOVERY.md` |
| Wiederkehrende Restore-Drills | Vaultwarden, Gitea, Authelia, Komodo, Paperless, Immich, Traefik, PostgreSQL, Mongo, Nextcloud, Mealie, Mail-Archiver nach Matrix-Intervallen rotieren | `docs/RESTORE_MATRIX.md`, `docs/RESTORE_HANDBOOK.md` |
@@ -98,6 +98,7 @@ Wartet auf ein externes Ereignis oder eine Abhaengigkeit.
- `docs/FAMILY_ONBOARDING.md`: Michi-Checkliste in eine echte Erste-Termin-Checkliste (Vorbereitung, Reihenfolge, Erfolgskriterium, bewusst spaeter) umgebaut.
- `docs/MASTER_TODO.md` in vier Status-Kategorien (Aktiv / Operator-Entscheidung / Geparkt / Extern blockiert) umstrukturiert.
- `baerchen` Veeam-Erstbackup: erster Full-Lauf 2026-06-05 erfolgreich geschrieben (Veeam-GUI 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen, VSS `job: success`). Beleg in `ops/windows-reinstall/docs/windows-image-backup-baseline.md`; Veeam Storage Encryption war im ersten Lauf nicht aktiv und ist als Operator-Entscheidung nachgezogen.
- Docker Critical Events Watcher auf Unraid aktiviert: Host-Clone auf Commit `2f3d184` aktualisiert, User Script `/boot/config/plugins/user.scripts/scripts/docker-critical-events-at-start/script` auf den Supervisor umgestellt, altes Script als `script.bak-20260605-232621` gesichert, `schedule.json` zeigt `frequency: start`, Watcher laeuft mit PID `1681168`. ntfy-Smoke bewusst nicht nachts gesendet.
---
docs/NETWORK_INVENTORY.md
+72 -13
View File
@@ -91,22 +91,81 @@ tailscale ip -4
tailscale ip -6
```
### ACL-Policy (Operator-Entscheidung offen)
### ACL-Policy — Entwurf und Rollout-Plan (Stand 2026-06-05, NICHT angewendet)
Die Tailnet-ACL ist aktuell nicht im Repo gespiegelt. Sie wird in der
Tailscale-Admin-Konsole unter `Access controls` verwaltet (kein Wert/Secret
gehoert ins Repo). Offene Entscheidung:
Die Tailnet-ACL wird in der Tailscale-Admin-Konsole unter `Access controls`
verwaltet (kein Wert/Secret gehoert ins Repo). Aktueller Live-Stand ist
Default-Allow (`src: ["*"] -> dst: ["*:*"]`), d. h. jedes Tailnet-Geraet darf
alles inklusive der LAN-Subnet-Route.
- Default-Allow belassen (jedes Tailnet-Geraet darf alles, inkl. der
LAN-Subnet-Route), **oder**
- restriktivere, Tag-basierte ACL einfuehren: nur Operator-Geraete duerfen die
Subnet-Route `192.168.178.0/24` und die Admin-Ports nutzen, Familien-/Mobil-
geraete nur die explizit benoetigten Dienste.
**Abgestimmte Richtung (Operator-Entscheidungen 2026-06-05):**
Empfehlung (zur Entscheidung, nicht umgesetzt): Da der Subnet-Router das ganze
LAN ins Tailnet bringt, ist eine restriktive ACL der wirksamste Hebel. Naechster
Schritt waere, die aktuelle Policy read-only aus der Admin-Konsole zu sichten
und dann eine Tag-Struktur (`tag:operator`, `tag:family`) zu entwerfen.
- Ziel ist eine restriktivere, Tag-basierte ACL.
- Single-User-Realitaet: aktuell gehoeren alle Nodes demselben User
`michaelkaleschke@`. Eine Differenzierung Operator/Familie ist nur ueber
**Tags** moeglich. Tagging aendert Ownership/Key-Expiry und erfordert je Geraet
Re-Auth — deshalb bewusst ein eigener, spaeterer Schritt.
- **Heute bewusst nur Sichtung + Entwurf, kein Tagging, keine Anwendung.**
- Familiengeraete brauchen Tailnet-Zugriff auf **bestimmte** Dienste (welche
genau, ist noch zu konkretisieren) — `tag:family` bekommt gezielte `dst`-Regeln.
- `iphone-14` ist ein Operator-Geraet und faellt unter `tag:operator`.
**Geraete -> Tag (fuer den spaeteren Tagging-Schritt):**
| Tag | Geraete |
|---|---|
| `tag:server` | `kallilabcore` (Host, Subnet-Router) |
| `tag:operator` | `baerchen-1`, `iphone-14` |
| `tag:family` | kuenftige Familiengeraete |
**Entwurf (Vorschlag, noch nicht in der Konsole gespeichert):**
```json
{
"tagOwners": {
"tag:server": ["autogroup:admin"],
"tag:operator": ["autogroup:admin"],
"tag:family": ["autogroup:admin"]
},
"autoApprovers": {
"routes": { "192.168.178.0/24": ["tag:server"] }
},
"acls": [
{ "action": "accept", "src": ["tag:operator"], "dst": ["*:*"] },
{ "action": "accept", "src": ["tag:server"], "dst": ["tag:operator:*"] },
{ "action": "accept", "src": ["tag:family"], "dst": ["100.80.98.33:443"] }
],
"ssh": [
{ "action": "accept", "src": ["tag:operator"], "dst": ["tag:server"],
"users": ["root", "autogroup:nonroot"] }
]
}
```
> Die `tag:family`-`dst` `100.80.98.33:443` ist ein **Platzhalter** und wird
> durch die real benoetigten Familien-Dienste ersetzt, sobald diese feststehen.
**Lockout-sichere Reihenfolge (wenn die Umsetzung freigegeben wird):**
1. `tagOwners` + `autoApprovers` + neue ACL-Regeln speichern, **Allow-all-Regel
zunaechst behalten**.
2. Geraete taggen (`baerchen-1`, `iphone-14` -> operator; `kallilabcore` ->
server) und je Geraet die Verbindung verifizieren.
3. Subnet-Route bleibt approved (jetzt via `autoApprovers`/`tag:server`).
4. **Erst zuletzt** die Allow-all-Regel entfernen -> restriktiv schalten.
5. Sofort Smoke-Tests fahren (siehe unten).
**Smoke-Tests nach Anwendung:**
- `baerchen-1` erreicht Host: `ping 100.80.98.33`, `ssh kallilabcore hostname` (read-only).
- `baerchen-1` erreicht LAN ueber Route: z. B. AdGuard-Admin `http://100.80.98.33:8082`, `curl -kI https://192.168.178.58`.
- Falls testbar: ein nicht-Operator-Geraet erreicht Route/Admin-Ports **nicht** mehr.
- Host-Gegencheck: `tailscale status` zeigt alle Soll-Peers weiter verbunden.
**Noch offene Eingaben vor Finalisierung:**
1. Aktueller ACL-JSON aus der Admin-Konsole (read-only gesichtet, nur Struktur dokumentiert).
2. Konkrete Liste der Dienste/Ports, die Familiengeraete ueber Tailscale brauchen.
## Portfreigaben und Exposure