sorb/axion1337.chat-gitops
1
0
Fork 0
Code Issues Pull Requests Packages Projects 1 Releases 24 Wiki Activity
Files
0213b0fe580742293422b10a5a4c18f5360c6a3d
axion1337.chat-gitops/docs/TASKS.md
T

27 KiB
Raw Blame History

aXion1337.Chat – Task List & Meilensteine

Last Updated: 2026-07-28
Statusübersicht: [✅ 13 Abgeschlossen] [🔄 0 In Progress] [📋 8+ Pending] [🔒 10 Security]

📊 Status Summary (Quick View)

Kategorie Count Status Details
Completed 13 ✅ Done K3S, Flux, ESS, Themes, Desktop, Monitoring, TURN, Authentik (Deploy+Enrollment/Recovery/2FA), Firewall, SSH, coturn Fix, Element Call Fork, NetworkPolicies
In Progress 0 🔄 — —
Backlog 8+ 📋 Pending DB Backups, PostgreSQL Migration, MAS-Template-Link, VP9-Retry
Security Tasks 5 🔒 Pending auditd, Kernel hardening, CrowdSec, Falco, WAF

Priority Distribution

Priority Count Timeline
🔴 CRITICAL 3 This week
🟠 HIGH 4 1–2 weeks
🟡 MEDIUM 8 ~1 month
🟢 LOW 4+ Nice-to-have

🗓️ Session-Zusammenfassung 2026-07-27/28 (fortlaufend aktualisiert)

Nach längerer Pause wiederaufgenommen — Mac war neu aufgesetzt, Zugriff (SSH, Kubeconfig, age-Key, Homebrew/flux/helm/sops/age) komplett wiederhergestellt und dauerhaft in ~/.zshrc verankert. Was in dieser Session erledigt wurde:

  1. Authentik Enrollment/Recovery/2FA (Issue #7 ✅ geschlossen) — siehe Phase 8 unten und docs/troubleshooting/README.md. matrix-invitation- und matrix-recovery-Flows waren kaputt bzw. leer, jetzt als Authentik Blueprint (apps/authentik/authentik-blueprints.yaml) deklarativ repariert. E2E mit echten Test-Usern (clark, lucky) verifiziert.
  2. coturn-Crash behoben — Liveness-Probe nutzte netstat (existiert nicht im Image), Server killte einen gesunden Prozess seit 88 Tagen, 36.000+ Restarts. Auf tcpSocket-Probe umgestellt, läuft seitdem stabil.
  3. Element Call Fork (Issue #8 ✅ geschlossen, Release m6-element-call-fork-complete) — 1440p/60fps-Defaults, siehe Kapitel 4 in docs/deployment-guides/04-element-customization.md. Wichtig: erzwungenes video_codec: vp9 hat Calls kurzzeitig live komplett kaputt gemacht (kein Bild/Ton) — sofort zurückgerollt, ohne Codec-Zwang läuft's. Root Cause dafür nicht abschließend isoliert, nur umgangen.
  4. Identitäts-Aufräumarbeiten: sorB's Authentik-E-Mail korrigiert (thorec@hotmail.de), MAS OIDC-Link (upstream_oauth_links) von sorB zeigte fest auf den alten MAS-User akadmin/@akadmin:axion1337.chat (Sub-Hash ist stabil über Username-Renames, daher blieb die Verknüpfung nach dem Rename "akadmin"→"sorB" bestehen) — umgehängt auf sorb/ @sorb:axion1337.chat. Neue Identität elbojoloco angelegt (E-Mail cfx@riot.8shield.net), verknüpft mit dem alten akadmin-MAS-User. Übrig: ein leeres, unverknüpftes @bojeledoggo:axion1337.chat-Konto (Tippfehler-Artefakt) — User räumt das selbst auf.
  5. NetworkPolicies (Issue #10 ✅ geschlossen) — siehe "Network Security" Abschnitt unten. Zwei Live-Incidents beim Rollout (Port-Verwechslungen), beide binnen Minuten live gepatcht und danach committed. Nebenbei: matrixRTC-Authorisation-Service OOM-Fix (20Mi→128Mi).
  6. Element Call Qualität nachgeschärft — 720p-Zwischen-Simulcast-Layer ergänzt (sonst harter Sprung von 1440p auf blockiges 360p bei kleinsten Netzwerkschwankungen), und video_codec: h264 statt VP8 (klassisches Simulcast wie VP8, kein SVC-Risiko wie bei VP9, oft hardwarebeschleunigt v.a. auf iOS). Live verifiziert: 7/8 Tracks nativ H.264, 1 sauberer VP8-Fallback. Deployed als v0.2.3-elementcall-h264.
  7. Backlog nach Gitea migriert — restlicher offener Backlog (VP9-Retry, ThreadNet-Web-Bug, MAS-Template-Link, WAF und 17 weitere Security-/Infra-Punkte) als Issues #11–#31 angelegt, veraltete erledigte Punkte (Authentik Stage 2/E2E-Test/Invite-Links, Hetzner-Firewall, SSH-Hardening) aus dieser Datei entfernt bzw. als done markiert.

Offene Punkte

  • VP9-Retry: vermutete Ursache jetzt bekannt (LiveKit nutzt SVC für vp9/av1, Fork-Code setzt aber immer Simulcast-Layer) — braucht einen Code-Fix in buildPublishOptions() (src/livekit/options.ts) bevor erneut versucht wird. Stattdessen H.264 probiert (siehe unten) — läuft gut, kein SVC-Risiko, hardwarebeschleunigt auf mehr Geräten.
  • ThreadNet-Web Build-Bug: scripts/docker-link-repos.sh/docker-package.sh nicht ausführbar committet + veralteter matrix-js-sdk#develop-Pin im Lockfile blockiert vollständigen Neu-Build des Web-Forks. Noch nicht gefixt, User hat noch nicht final entschieden ob gewünscht.
  • Verwaistes @bojeledoggo:axion1337.chat: leeres Matrix-Konto ohne OIDC-Link, User räumt das selbst auf (braucht dafür seinen eigenen Access-Token für die Admin-API).
  • MAS-Template-Link: 2FA/Passkey-Setup-Links direkt auf account.axion1337.chat/account/ statt nur über docs/setup/security.html — braucht MAS Custom-Template-Override (templates.path), größerer separater Task.
  • Nächste Kandidaten aus den offenen Issues: #6 (DB-Backup, CRITICAL), #9 (PostgreSQL-Migration), #10 (NetworkPolicies).

🎯 Next Steps (Priorisiert)

🔴 THIS WEEK – CRITICAL

  1. ✅ Authentik Stage 2 abschließen

    • ✅ Manual: OIDC Provider + Application in Authentik UI erstellt
    • ✅ Code: upstream_oauth2_config in mas-secret.yaml eingefügt
    • ✅ Code: passwords: enabled: false aktiviert
    • ✅ Commit: cdfbf7d - Enable Authentik OIDC integration in MAS
    • ✅ Verified: Login mit Authentik funktioniert (2026-05-15)
    • Status: COMPLETE

  2. ✅ Hetzner Cloud Firewall – Optimierte Konfiguration

    • ✅ Ingress: 80/443 + TURN/STUN + RTC Services
    • ✅ SSH: Spezifische IPs (port 2248, nicht 22)
    • ✅ Default-Deny für nicht-definierte Traffic
    • Status: COMPLETE (optimiert über Plan)

  3. ✅ SSH Hardening

    • ✅ PasswordAuthentication: no (key-only)
    • ✅ PermitRootLogin: no (root disabled)
    • ✅ MaxAuthTries: 3 (verified 2026-05-15)
    • Status: COMPLETE

  4. Database Backup Strategy – Decision & First Backup

    • ⏳ Decision: CloudNativePG (on K3S) or Hetzner Postgres (managed)?
    • ⏳ Setup: Daily automated backups
    • ⏳ Setup: Off-site storage (S3 / Storage Box)
    • ⏳ Setup: Monthly verified restores
    • Est. Time: 2–3 days
    • Priority: CRITICAL (disaster recovery)
    • Status: NEXT

🟠 NEXT 1–2 WEEKS – HIGH

  1. ✅ Authentik End-to-End Test — erledigt als Teil von Issue #7 (Enrollment/Recovery/2FA, 2026-07-27), mit echten Test-Usern verifiziert. Status: COMPLETE

  2. ✅ Element Call Fork — erledigt, Closes Issue #8 (2026-07-28), siehe docs/deployment-guides/04-element-customization.md Kapitel 4. Status: COMPLETE

  3. External PostgreSQL Migration → Issue #9

    • Decision: CloudNativePG vs. Hetzner Postgres
    • Setup: HA + Replication
    • Migration: Move data from ESS embedded Postgres
    • Testing: Verify all services work
    • Est. Time: 1–2 days

  4. ✅ NetworkPolicies Deployment — erledigt, Closes Issue #10 (2026-07-28), Default-Deny für matrix+authentik Namespaces. Status: COMPLETE

🗓️ Session-Zusammenfassung 2026-07-30 bis 2026-08-01 (CI/CD-Umzug ins Lab)

  1. CI/CD komplett ins Homelab-GitLab migriert (git.lab, nur im Lab auflösbar) — nach vier realen Gitea-Actions/act-Bugs und einem verifizierten Webpack-OOM auf dem 3,7-GiB-CFGMON-Runner. ThreadNet-Web-Pipeline vollautomatisch grün (Web-Build, Image-Push nach rohana, Desktop-Linux deb/tar.gz). Schlankes Trigger-Schema: Pushes prüfen nur bei relevanten Pfaden, Artefakte entstehen bei v*-Tags. (ThreadNet-Web#2 ✅ geschlossen)
  2. Repo-Topologie neu: git.lab ist kanonisch für gitops, ThreadNet-Web, threadnet-call, thread-net-git, threadnet-operating — Push-Mirrors nach Gitea, das Flux-Quelle/Registry/Issues behält. Details: README §3 / CLAUDE.md.
  3. Windows-Build-Strecke (ThreadNet-Web#5): eigene Windows-VM auf Overmind aus selbst gebautem, reviewtem dockur/windows-Stand (Vendor-Repo + Runbook), On-Demand per CI-Jobs; Gast provisioniert, Runner registriert — erster voller Build-Durchlauf stand zum Session-Ende noch aus (Runner-Dienst-Hänger nach VM-Neustart).
  4. Lab-Container-Registry aktiviert (registry.git.lab, OVERMIND-01 ✅): lab-interne Build-Images (windows-vm, desktop-build) bleiben im Lab, rohana behält nur, was Prod konsumiert.
  5. Gitea-CI-Rückbau (CFGMON-11, weitgehend): Verifikations-Job hierher portiert (.gitlab-ci.yml), .gitea/workflows/ entfernt, Actions-Toggles deaktiviert, Runner-Entfernung als Commit vorbereitet — drei manuelle Restschritte beim Nutzer.
  6. threadnet-call-CI (threadnet-call#1): build_embedded grün, npm-Registry bleibt evidenzbasiert auf rohana (pnpm-Lockfile-Pin), manueller Publish-Job wartet auf GITEA_NPM_TOKEN-Variable.
  7. Alerting vorbereitet (Issue #32): Alertmanager + 6 Alert-Regeln + Matrix-Receiver in threadnet-operating, gelintet, Deploy steht aus (CFGMON).
  8. Nebenbefunde: GitLab-Puma lief mit ~17 Workern (Unicorn-Fossil in der Config, Fix beim Nutzer), Windows-Gast-Provisionierung als idempotenter CI-Job.

✅ Abgeschlossene Aufgaben (Chronologisch)

Phase 1: Basis-Setup

  • K3S Cluster aufsetzen – Single-Node auf Hetzner Cloud (49.13.132.245)

    • Commit: initial-setup (vor Projekt)
    • Status: ✅ Läuft

  • Flux CD Installation

    • SOPS + age Encryption
    • GitOps Repository konfigurieren
    • Commit: setup-flux (vor Projekt)
    • Status: ✅ Läuft

  • Element Server Suite v26.4.0 Deployment

    • Synapse Homeserver (matrix.axion1337.chat)
    • Matrix Authentication Service (account.axion1337.chat)
    • Element Web (axion1337.chat)
    • Element Admin (admin.axion1337.chat)
    • MatrixRTC/Element Call (mrtc.axion1337.chat)
    • Commit: deploy-ess-matrix-stack
    • Status: ✅ Running

Phase 2: Core Features

  • 7 Custom Element Web Themes

    • aXion1337 Dark, Deep Purple, Discord Dark, Electric Blue, Everforest, Gruvbox, Wal
    • Alphabetisch sortiert
    • Commit: add-custom-element-themes
    • Status: ✅ Deployed

  • Element Desktop Setup Scripts (Windows/macOS/Linux)

    • Auto-Download + Install + Config
    • Hosted auf axion1337.chat/docs/setup/
    • Commits: add-element-desktop-setup-scripts, fix-element-setup-script-hosting
    • Status: ✅ Deployed

  • Room Policies

    • Message Retention (1d–1y lifecycle)
    • Room Publication Rules (allow all)
    • Auto-Join Rooms für Onboarding
    • Commit: add-synapse-retention-publication-autojoin
    • Status: ✅ Deployed

Phase 3: WebRTC & Medienübertragung

  • TURN Server (coturn) für Video-Calls
    • Domain: turn.axion1337.chat
    • HMAC-Auth mit Shared Secret
    • Ports: 3478/udp, 3478/tcp, 5349/tcp, 49152-65535/udp
    • Commit: implement-turn-server-coturn-for-webrtc-video-calls
    • Status: ✅ Deployed
    • Manual: DNS A-Record + Firewall-Ports öffnen (noch erforderlich)

Phase 4: Monitoring & Observability

  • Monitoring Stack Integration
    • Alloy (Grafana Agent) als Collector
    • Remote Write zu Selendis (10.0.0.3:9090 Prometheus, :3100 Loki)
    • kube-state-metrics, node-exporter DaemonSet
    • Commits: integrate-monitoring-alloy-prometheus-loki, fix-prometheus-remote-write-docker
    • Status: ✅ Deployed

Phase 5: Identity Provider (Authentik)

  • Authentik Stage 1 Deployment

    • HelmRelease v2026.x in authentik namespace
    • Embedded PostgreSQL + Alloy-compatible
    • Cert-Manager für TLS
    • Commit: deploy-authentik-as-identity-provider-for-matrix-stage-1
    • Status: ✅ Deployed
    • Manual: Admin-Passwort + OIDC Provider + Application + Enrollment Flow erstellt ✅

  • Authentik Stage 2 – MAS Integration

    • ✅ Authentik Admin UI: OIDC Provider erstellt (Authentik)
    • ✅ Authentik Admin UI: Application mit Slug matrix erstellt
    • ✅ Authentik Admin UI: Enrollment Flow mit Invitation Stage konfiguriert
    • ✅ Client ID + Secret kopiert
    • ✅ MAS upstream_oauth2_config mit Client Credentials aktualisiert
    • ✅ passwords: enabled: false aktiviert
    • ✅ Commit: cdfbf7d - Enable Authentik OIDC integration in MAS
    • ✅ Verified: Login mit Authentik funktioniert (2026-05-15)
    • Status: ✅ Deployed & Verified

Phase 6: Dokumentation

  • Deployment Guides erstellen

    • 5 Markdown-Dateien in docs/deployment-guides/
    • Chronologisch geordnet
    • Troubleshooting + Best Practices
    • Commit: add-comprehensive-deployment-configuration-documentation
    • Status: ✅ Deployed

  • Gitea Wiki erstellen

    • Home.md mit Navigation
    • Alle Deployment Guides in Root
    • Operations + Archive Dokumentation
    • Wiki Branch gepusht zu rohana.axion1337.de
    • Status: ✅ Live

  • Gitea Issues & Project Board

    • 8 Issues erstellt (#3-#10): 4 CRITICAL + 4 HIGH
    • Priority Labels: critical, high
    • Area Labels: authentik, security, database, infrastructure, element
    • Status: ✅ Tracking

Phase 7: Infrastructure Security (Critical)

  • Hetzner Cloud Firewall Configuration

    • SSH: Spezifische IPs (port 2248)
    • HTTP/HTTPS: Any IPv4/IPv6
    • TURN/STUN: WebRTC Ports
    • RTC Services: SFU + Auth Ports
    • Status: ✅ Optimiert & Deployed

  • SSH Hardening

    • PasswordAuthentication: no (key-only)
    • PermitRootLogin: no
    • MaxAuthTries: 3
    • Verified: 2026-05-15
    • Status: ✅ Complete

🔄 In Progress / Blocked

None – Alle CRITICAL Tasks erledigt! Nächster Focus: Database Backups

Phase 8: Authentik Enrollment/Recovery/MFA Fix (2026-07-27)

  • matrix-invitation Flow repariert – fehlende Write/Password/Login-Stages ergänzt, Reihenfolge korrigiert, als Authentik Blueprint (apps/authentik/authentik-blueprints.yaml) reproduzierbar gemacht
  • matrix-invitation-prompt – 16 fehlerhafte validation_policies entfernt (crashten mit AnonymousUser/NoneType-Fehlern)
  • Redirect-Stage – Flow endet jetzt auf axion1337.chat statt in der /if/user/-Sackgasse (blockiert für type=external)
  • matrix-recovery Flow gebaut – war komplett leer (0 Stages); Passwort-Reset funktioniert jetzt, verlinkt von der echten Login-Seite
  • Brand.default_application gesetzt – behebt mehrere Dead-Ends, wenn eingeloggte User / ohne Ziel aufrufen
  • 2FA/Passkey Selbst-Einrichtung – Links zu default-authenticator-totp-setup/-webauthn-setup (2FA bleibt optional, not_configured_action=skip), dokumentiert unter axion1337.chat/docs/setup/security.html
  • Backlog: Issue #13 geschlossen (2026-07-29) - MAS-Template-Override verworfen, MAS unterstützt laut live geprüfter OIDC-Discovery keine 2FA/Passkey-Deep-Link-Action. Jetzt als Client-Änderung nachgehalten: ThreadNet-Web#4

📋 Backlog (Weitere Aufgaben)

Ab 2026-07-28 in Gitea-Issues gepflegt statt hier (eine Quelle der Wahrheit) — offene Issues: #6 DB-Backup-Strategie, #9 Externe PostgreSQL-Migration, #11–#31 (VP9-Retry, ThreadNet-Web-Build-Bug, MAS-Template-Link, WAF, Media-PVC-Backups, Pod Security Admission, Federation-Allowlist, Mjolnir/Draupnir, Content-Scanner, External-Secrets, Renovate/Trivy, Security-Advisory-Monitoring, automountServiceAccountToken, unattended-upgrades, K3s-API-Security, auditd, Kernel-Hardening, Lynis, CrowdSec, Falco). Die detaillierten Beschreibungen unten sind das historische Original, aus dem die Issues entstanden sind — nicht mehr getrennt pflegen, stattdessen die Issues aktuell halten.

Element Call Enhancement

  • Element Call Fork für Custom Constraints (2026-07-28, Closes #8)
    • Fork: rohana.axion1337.de/sorb/threadnet-call (basiert auf emmick4/element-call:livekit, das den noch nicht gemergten Upstream-PR element-hq/element-call#3736 enthält — config-driven media_quality, keine Custom-Logik nötig)
    • Defaults angehoben: Video bis 1440p/60fps (~8 Mbps), Screen-Share 1440p/30fps (~6 Mbps). Das sind Startwerte, keine harten Limits — Nutzer können in den Settings weiter hochdrehen.
    • Incident (2026-07-28): Erster Deploy (v0.2.0, mit video_codec: vp9 erzwungen) hat Calls komplett kaputt gemacht (kein Bild/Ton), obwohl LiveKit-Server-Logs den Codec-Regression-Fallback auf VP8 als erfolgreich zeigten — Root Cause nicht abschließend isoliert. Sofort auf v0.1.0 zurückgerollt, dann v0.2.1 ohne erzwungenen Codec (Standard VP8) mit denselben 1440p/60fps-Werten deployed und vom Nutzer live bestätigt: funktioniert. VP9-Präferenz vorerst fallengelassen, siehe Backlog.
    • Rauschunterdrückung: nur clientseitige WebRTC-Standardtoggles (echoCancellation/ noiseSuppression/autoGainControl), kommt kostenlos mit derselben PR. Bewusst kein server-seitiges ML-Noise-Cancellation (LiveKit Agents + DTLN/RNNoise) — laut LiveKits eigener Doku ist das für Mensch-zu-Mensch-Calls der falsche Ansatz (nur für AI-Voice-Agents gedacht, kein Standard-Pfad um bereinigtes Audio an andere Teilnehmer zurückzugeben).
    • Well-Known/org.matrix.msc4143.rtc_foci-Delegation war schon vom ESS-Chart korrekt automatisch konfiguriert — kein Handlungsbedarf trotz anderslautendem Issue-Text.
    • Deployment-Ansatz geändert: sorb/ThreadNet-Web (der Element-Web-Fork) hat einen vorbestehenden, unabhängigen Build-Bug (siehe unten) und ließ sich nicht komplett neu bauen. Stattdessen: nur der /app/widgets/element-call/-Ordner im bereits laufenden threadnet-web:v0.1.0-Image ausgetauscht → neues Image rohana.axion1337.de/sorb/threadnet-web:v0.2.0-elementcall-mediaquality.
    • Verifiziert: media_quality live auf axion1337.chat/widgets/element-call/config.json.
    • Gefunden, nicht gefixt: ThreadNet-Web lässt sich aktuell nicht komplett neu bauen — scripts/docker-link-repos.sh/docker-package.sh sind im Repo nicht ausführbar committet (Mode 644 statt 755), UND der gepinnte matrix-js-sdk#develop-Commit im Lockfile ist zu alt (fehlt src/oidc/authorize.ts, das apps/web importiert). Beides unabhängig von diesem Fix, blockiert aber jeden zukünftigen vollständigen Rebuild. Update 2026-07-28 (Issue #12): behoben — Skript-Rechte korrigiert, matrix-js-sdk auf einen funktionierenden Commit (d19cb751, letzter vor einem API-Breaking-Rename) gepinnt, zusätzlich gefunden+gefixt: Element-Call-Referenz zeigte noch auf Upstream statt unseren Fork. Mit echtem Full-Docker-Build verifiziert, siehe Element-Customization Wiki.
    • Backlog: MAL-basierte Noise-Cancellation (LiveKit Agents + self-hosted DTLN/RNNoise) als experimentelle Idee, falls später gewünscht — kein etablierter Pfad für Conferencing.
    • Backlog: VP9-Codec-Präferenz erneut versuchen, sobald PR #3736 upstream gemerged/gereift ist oder Root Cause des Ausfalls isoliert wurde (Browser-Konsolen-Repro nötig).

Database Hardening

  • External/Dedizierte PostgreSQL-Migration → Issue #9

(Database Backup Strategy und Synapse Media PVC Backups waren hier ursprünglich als eigene Punkte gelistet - beide erledigt und geschlossen, siehe #6 und #15, Details in 00-TASKS Wiki bzw. Release v0.16.0.)

Network Security

  • NetworkPolicies – K8s-Layer Segmentation (2026-07-28, Closes #10)

    • Default-Deny Ingress (egress left untouched) für matrix UND authentik namespaces, per-Komponente Allow-Regeln in apps/authentik/networkpolicy.yaml und apps/production/networkpolicy.yaml. Rollout: authentik zuerst als Pilot, dann matrix.
    • Empirisch verifiziert, dass K3s' eingebauter NetworkPolicy-Controller tatsächlich durchsetzt (Testnamespace, Timeout- statt Refused-Verhalten unter Deny-Policy).
    • Zwei Live-Incidents beim Rollout, beide binnen Minuten behoben:
      1. authentik-server: Regel erlaubte Service-Port 80/443, aber NetworkPolicy filtert auf dem tatsächlichen Container-Port (9000/9443 nach kube-proxy-DNAT) — 502 auf auth.axion1337.chat, sofort korrigiert.
      2. matrix-authentication-service: Regel erlaubte Synapse nur auf Port 8081, aber Synapse ruft /oauth2/introspect tatsächlich auf Port 8080 — jede authentifizierte Anfrage (inkl. /sync) scheiterte mit 503, alle Clients zeigten "Verbindung unterbrochen". Live gepatcht, dann committed.
    • Lehre für zukünftige NetworkPolicies in diesem Repo: wo immer ein Service benannte Ports (targetPort: <name>) nutzt, diese direkt in der Policy referenzieren statt Portnummern zu raten — schließt genau diese Fehlerklasse aus.
    • Nebenbefund (unabhängig von NetworkPolicies): matrixRTC-Authorisation-Service hatte ein 20Mi-Memory-Limit (Chart-Default), OOM-gekillt nach ~74 Tagen Uptime während der Verifikations-Calls — auf 64Mi/128Mi angehoben.
    • coturn (hostNetwork) bewusst ausgenommen — NetworkPolicy greift dort nicht.
    • authentik-postgresql's Bitnami-Chart-Policy (Port 5432, quelloffen) bewusst nicht angefasst/dupliziert, da Helm-verwaltet.

  • Pod Security Admission (Restricted) → Issue #16

Federation & Access Control

  • Federation-Allowlist oder Closed Federation → Issue #17

Moderation & Anti-Abuse

  • Draupnir Moderationsbot → Issue #18 (2026-07-29, deployed + live getestet)
  • Content Scanner für Media → Issue #19 (2026-07-29, Synapse-Modul + ClamAV für unverschlüsselte Räume, plus client-seitiger Scan im ThreadNet-Web-Fork für verschlüsselte Räume/DMs - live getestet, beide Richtungen; siehe Deployment-Guide)
  • Grafana-Dashboard für ClamAV-Erkennungen → Issue #43
  • ThreadNet-Web: Electron-Desktop-Build automatisieren → Issue #44 (kein CI-Runner, Fork-Änderungen landen aktuell nicht automatisch im Desktop-Client)

Secrets Management

  • External-Secrets Operator vs. SOPS-Setup → Issue #20

Image & Dependency Management

Container Security

  • automountServiceAccountToken deaktivieren wo nicht benötigt → Issue #23

🔒 Security Hardening (Host & Cluster Level)

Host OS Layer (Ubuntu/Debian)

  • Hetzner Cloud Firewall – Default-Deny inbound, siehe "Phase 7" oben. Done.

  • SSH Hardening – Key-only, Root-Login disabled, Port 2248, siehe "Phase 7" oben. Done.

  • unattended-upgrades (2026-07-30) – war bereits aktiv (APT::Periodic::* seit längerem gesetzt, Origins-Pattern deckt Debian+Debian-Security ab), nur nie dokumentiert. Ergänzt: Pre-Update-Benachrichtigung per Mail+Matrix, fest vor dem 06:00-07:00-Update-Fenster. Siehe 07-host-maintenance-notifications.md. Closes Issue #24

  • K3s API Security Hardening → Issue #25

  • auditd (File Integrity & Syscall Audit) → Issue #26

  • Kernel Hardening (sysctl) → Issue #27

  • Lynis Security Baseline → Issue #28

Cluster Layer (K3S / Kubernetes)

🎯 Versionierung

Seit 2026-07-28 SemVer statt der alten m1-m7-Meilensteine - siehe Releases für die volle, detaillierte Historie (aktuell bis v0.17.0) und 00-TASKS im Wiki für die Konvention (MINOR = neue Fähigkeit, PATCH = Fix/Tuning/Doku).

📊 Prioritäts-Kategorien

Alle Punkte hier sind als Gitea-Issues nachgehalten (Nummern siehe oben/Backlog-Verweis) - diese Kategorisierung ist nur eine grobe Einordnung, keine zweite Tracking-Quelle.

🟠 HIGH

  • External PostgreSQL migration (#9)

🟡 MEDIUM (do within 1 month)

  • CrowdSec + Falco (#29, #30)
  • Renovate/Trivy (#31, #32)
  • K3s API Hardening, auditd, Kernel Hardening, Lynis (#25-#28)

🟢 LOW (nice-to-have, do if time allows)

  • External-Secrets upgrade
  • Advanced federation rules

📝 Notes & Decision Points

Database: CloudNativePG vs. Hetzner Postgres

  • CloudNativePG: Open-source, runs on K3S, full control
  • Hetzner Postgres: Managed, backups included, less ops overhead
  • Decision: Recommend CloudNativePG for now (cost-effective), migrate to Hetzner later if operational overhead too high

Federation: Allowlist vs. Closed?

  • Allowlist: Default federation with all public servers, can be attacked
  • Closed: Only federate with trusted servers (higher security, lower interop)
  • Decision: Depends on user intent. For now: allow all, add Mjolnir for abuse protection

Security Framework

  • Layers: Perimeter (Firewall) → Host (SSH, auditd, hardening) → Cluster (NetworkPolicies, PSA, Falco) → App (Rate-limits, Mjolnir)
  • Approach: Implement incrementally, test after each layer

🔗 Related Documentation

  • docs/deployment-guides/README.md – Overview
  • docs/deployment-guides/01-turn-server-setup.md – TURN
  • docs/deployment-guides/02-authentik-identity-provider.md – Authentik (Stage 1+2 + Enrollment/Recovery/2FA)
  • docs/deployment-guides/03-monitoring-integration.md – Monitoring
  • docs/deployment-guides/04-element-customization.md – Themes, Desktop, Element Call Fork
  • docs/deployment-guides/05-room-policies.md – Policies
  • docs/deployment-guides/06-moderation-content-scanning.md – Draupnir, ClamAV Content Scanning
  • docs/deployment-guides/07-host-maintenance-notifications.md – Host-Wartungsbenachrichtigungen

Last Updated: 2026-07-30

Reference in New Issue View Git Blame Copy Permalink