Documentation audit across the repo found several places still describing finished work as pending or in-progress (Authentik Stage 2, Element Call fork, NetworkPolicies in TASKS.md's own Next Steps section, the Boje troubleshooting entry). Also moves CLAUDE.md from the untracked parent directory into the repo root and brings its content up to date, and documents the new host-config/ pattern in README.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
25 KiB
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:
- Authentik Enrollment/Recovery/2FA (Issue #7 ✅ geschlossen) — siehe Phase 8 unten und
docs/troubleshooting/README.md.matrix-invitation- undmatrix-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. - coturn-Crash behoben — Liveness-Probe nutzte
netstat(existiert nicht im Image), Server killte einen gesunden Prozess seit 88 Tagen, 36.000+ Restarts. AuftcpSocket-Probe umgestellt, läuft seitdem stabil. - Element Call Fork (Issue #8 ✅ geschlossen, Release
m6-element-call-fork-complete) — 1440p/60fps-Defaults, siehe Kapitel 4 indocs/deployment-guides/04-element-customization.md. Wichtig: erzwungenesvideo_codec: vp9hat 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. - Identitäts-Aufräumarbeiten:
sorB's Authentik-E-Mail korrigiert (thorec@hotmail.de), MAS OIDC-Link (upstream_oauth_links) vonsorBzeigte fest auf den alten MAS-Userakadmin/@akadmin:axion1337.chat(Sub-Hash ist stabil über Username-Renames, daher blieb die Verknüpfung nach dem Rename "akadmin"→"sorB" bestehen) — umgehängt aufsorb/@sorb:axion1337.chat. Neue Identitätelbojolocoangelegt (E-Mailcfx@riot.8shield.net), verknüpft mit dem altenakadmin-MAS-User. Übrig: ein leeres, unverknüpftes@bojeledoggo:axion1337.chat-Konto (Tippfehler-Artefakt) — User räumt das selbst auf. - 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). - 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: h264statt 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 alsv0.2.3-elementcall-h264. - 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-WebBuild-Bug:scripts/docker-link-repos.sh/docker-package.shnicht ausführbar committet + veraltetermatrix-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 überdocs/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
-
✅ Authentik Stage 2 abschließen
- ✅ Manual: OIDC Provider + Application in Authentik UI erstellt
- ✅ Code:
upstream_oauth2_configinmas-secret.yamleingefügt - ✅ Code:
passwords: enabled: falseaktiviert - ✅ Commit:
cdfbf7d- Enable Authentik OIDC integration in MAS - ✅ Verified: Login mit Authentik funktioniert (2026-05-15)
- Status: COMPLETE
-
✅ 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)
-
✅ SSH Hardening
- ✅ PasswordAuthentication: no (key-only)
- ✅ PermitRootLogin: no (root disabled)
- ✅ MaxAuthTries: 3 (verified 2026-05-15)
- Status: COMPLETE
-
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
-
✅ Authentik End-to-End Test — erledigt als Teil von Issue #7 (Enrollment/Recovery/2FA, 2026-07-27), mit echten Test-Usern verifiziert. Status: COMPLETE
-
✅ Element Call Fork — erledigt, Closes Issue #8 (2026-07-28), siehe
docs/deployment-guides/04-element-customization.mdKapitel 4. Status: COMPLETE -
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
-
✅ NetworkPolicies Deployment — erledigt, Closes Issue #10 (2026-07-28), Default-Deny für
matrix+authentikNamespaces. Status: COMPLETE
✅ 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
- Commit:
-
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
- Synapse Homeserver (
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)
- Domain:
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
authentiknamespace - 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 ✅
- HelmRelease v2026.x in
-
Authentik Stage 2 – MAS Integration
- ✅ Authentik Admin UI: OIDC Provider erstellt (Authentik)
- ✅ Authentik Admin UI: Application mit Slug
matrixerstellt - ✅ Authentik Admin UI: Enrollment Flow mit Invitation Stage konfiguriert
- ✅ Client ID + Secret kopiert
- ✅ MAS
upstream_oauth2_configmit Client Credentials aktualisiert - ✅
passwords: enabled: falseaktiviert - ✅ 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
- 5 Markdown-Dateien in
-
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_policiesentfernt (crashten mitAnonymousUser/NoneType-Fehlern) - Redirect-Stage – Flow endet jetzt auf
axion1337.chatstatt in der/if/user/-Sackgasse (blockiert fürtype=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 unteraxion1337.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 aufemmick4/element-call:livekit, das den noch nicht gemergten Upstream-PR element-hq/element-call#3736 enthält — config-drivenmedia_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, mitvideo_codec: vp9erzwungen) 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 aufv0.1.0zurückgerollt, dannv0.2.1ohne 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 laufendenthreadnet-web:v0.1.0-Image ausgetauscht → neues Imagerohana.axion1337.de/sorb/threadnet-web:v0.2.0-elementcall-mediaquality. - Verifiziert:
media_qualitylive aufaxion1337.chat/widgets/element-call/config.json. - Gefunden, nicht gefixt:
ThreadNet-Weblässt sich aktuell nicht komplett neu bauen —scripts/docker-link-repos.sh/docker-package.shsind im Repo nicht ausführbar committet (Mode 644 statt 755), UND der gepinntematrix-js-sdk#develop-Commit im Lockfile ist zu alt (fehltsrc/oidc/authorize.ts, dasapps/webimportiert). 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).
- Fork:
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
matrixUNDauthentiknamespaces, per-Komponente Allow-Regeln inapps/authentik/networkpolicy.yamlundapps/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:
authentik-server: Regel erlaubte Service-Port 80/443, aber NetworkPolicy filtert auf dem tatsächlichen Container-Port (9000/9443 nach kube-proxy-DNAT) — 502 aufauth.axion1337.chat, sofort korrigiert.matrix-authentication-service: Regel erlaubte Synapse nur auf Port 8081, aber Synapse ruft/oauth2/introspecttatsä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.
- Default-Deny Ingress (egress left untouched) für
-
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
- Renovate/Dependabot Setup → Issue #21
- Trivy Image Scanning → Issue #31
- Security Advisory Monitoring (ESS/Element) → Issue #22
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– Overviewdocs/deployment-guides/01-turn-server-setup.md– TURNdocs/deployment-guides/02-authentik-identity-provider.md– Authentik (Stage 1+2 + Enrollment/Recovery/2FA)docs/deployment-guides/03-monitoring-integration.md– Monitoringdocs/deployment-guides/04-element-customization.md– Themes, Desktop, Element Call Forkdocs/deployment-guides/05-room-policies.md– Policiesdocs/deployment-guides/06-moderation-content-scanning.md– Draupnir, ClamAV Content Scanningdocs/deployment-guides/07-host-maintenance-notifications.md– Host-Wartungsbenachrichtigungen
Last Updated: 2026-07-30