Dokument 11: Analyse VM-basierte Kundenisolation

Qognio Bot-Plattform — Technische Isolationsoptionen

Erstellt: April 2026 Autor: fmhconsulting · Qognio Version: 1.0 Status: Entscheidungsvorlage

1. Ausgangslage

1.1 Aktuelle Architektur

Qognio betreibt KI-Bots (OpenClaw-basiert) als Managed Service für HR-Anwendungsfälle. Die aktuelle Infrastruktur:

• Hosting-Provider: KI-Bunker (dedizierte Hardware, Standort nördlich von Hamburg)
• Virtualisierung: Beide Server sind selbst KVM/QEMU-Gäste (Guest Agent installiert)
• Aktueller Stand: ~15 Docker-Container auf dem Bot-Server
• Provisioning: Node.js-basierter Provisioner (osagentsafehosting/provisioner/) mit Docker-API (dockerode)
• Isolation: Docker-Bridge-Netzwerke pro Mandant, separate Volumes, Memory/CPU-Limits

1.2 Motivation für stärkere Isolation

Die aktuelle Docker-basierte Mandantentrennung (vgl. TOMs Anlage 1, §1.4 Trennungskontrolle) bietet: - ✅ Logische Trennung (Namespaces, cgroups) - ✅ Separate Netzwerke und Dateisysteme - ⚠️ Gemeinsamer Kernel — Container teilen sich den Host-Kernel - ⚠️ Kernel-Exploits betreffen alle Mandanten gleichzeitig - ⚠️ DSGVO Art. 32 verlangt “dem Stand der Technik entsprechende” Maßnahmen

Für HR-Datenverarbeitung (Hochrisiko-KI nach EU AI Act Anhang III Nr. 4, vgl. DSFA Dokument 05) ist eine stärkere technische Mandantentrennung empfehlenswert — insbesondere wenn Kunden mit besonderen Datenkategorien (Gesundheitsdaten, Leistungsbeurteilungen) arbeiten.

1.3 Anforderungen

2. Optionsanalyse

2.1 Nested Virtualization (KVM-in-KVM)

Konzept: Vollständige virtuelle Maschinen innerhalb der bestehenden VMs starten. Jeder Kunde erhält eine eigene VM mit eigenem Kernel, eigenem Userland.

Technische Voraussetzungen: - CPU-Flag vmx (Intel) bzw. svm (AMD) muss im Guest sichtbar sein - Host-Hypervisor muss Nested Virtualization aktiviert haben (nested=1 in KVM-Modul) - Prüfung: cat /proc/cpuinfo | grep -E 'vmx|svm' auf .45

Bewertung:

Risiken: - Nested Virtualization muss vom Provider (KI-Bunker) am Hypervisor aktiviert werden - Performance-Degradation ist signifikant bei I/O-intensiven Workloads - Kernel-Updates in jeder Sub-VM müssen separat verwaltet werden - 16 GB RAM sind für >10 Kunden mit Nested VMs unzureichend

Fazit: Maximale Isolation, aber unpraktikabel auf aktueller Hardware. Nur sinnvoll bei deutlich mehr RAM (≥64 GB).

2.2 MicroVMs (Firecracker / Cloud Hypervisor)

Konzept: Leichtgewichtige VMs mit minimalem Footprint. Firecracker (von AWS für Lambda/Fargate entwickelt) startet VMs in ~125ms mit ~5 MB RAM-Overhead für den VMM-Prozess. Cloud Hypervisor (Intel/Microsoft) ist die Alternative mit mehr Features.

Funktionsweise: - Jeder Kunde erhält eine MicroVM mit eigenem Linux-Kernel - Minimales Root-Filesystem (Alpine/BusyBox-basiert, ~50-150 MB) - virtio-Netzwerk und -Block-Devices - KVM als Backend (benötigt /dev/kvm)

Bewertung:

Voraussetzungen: - /dev/kvm muss im Guest verfügbar sein → Nested Virtualization erforderlich! - Firecracker nutzt KVM direkt, funktioniert nicht ohne Hardware-Virtualisierung - Custom Root-Filesystem muss gebaut und gepflegt werden (z.B. mit firectl oder ignite)

Integration mit bestehendem Provisioner:

Aktuell:  API → dockerService.ts → Docker API → Container
Neu:      API → firecrackerService.ts → Firecracker API → MicroVM

• Der Provisioner müsste um einen firecrackerService erweitert werden
• Firecracker hat eine REST-API (Unix Socket), konzeptionell ähnlich wie Docker
• Templates müssten von Docker-Compose auf MicroVM-Konfiguration umgestellt werden

Risiken: - Gleiche Nested-Virt-Abhängigkeit wie Option 2.1 — ohne /dev/kvm unbenutzbar - Kein Docker-Ökosystem (Images, Compose, etc.) - Debugging komplexer als bei Containern - Netzwerk-Setup (TAP devices, Bridge) muss selbst implementiert werden

Fazit: Technisch die eleganteste Lösung, aber blockiert durch die gleiche Nested-Virtualization-Abhängigkeit. Wenn KI-Bunker /dev/kvm bereitstellt, ist dies die Top-Empfehlung für maximale Isolation bei minimalem Overhead.

2.3 Kata Containers

Konzept: OCI-kompatible Container-Runtime, die jeden Container in einer leichtgewichtigen VM startet. Kombination aus Container-API-Kompatibilität und VM-Isolation. Nutzt intern QEMU, Cloud Hypervisor oder Firecracker als VMM.

Funktionsweise: - Docker/containerd-kompatible Runtime (kata-runtime) - Jeder Container startet in einer eigenen VM mit eigenem Kernel - Transparenter Ersatz für runc — bestehende Docker-Compose-Dateien funktionieren - OCI-Images werden direkt verwendet (keine Custom Root-FS nötig)

Bewertung:

Integration mit bestehendem Provisioner:

Aktuell:  API → dockerService.ts → Docker API → runc → Container
Neu:      API → dockerService.ts → Docker API → kata-runtime → VM-Container

• Minimaler Code-Umbau: Docker-API bleibt, nur Runtime wechselt
• Konfiguration in /etc/docker/daemon.json oder containerd config
• Templates bleiben Docker-Compose-Dateien
• Optional: Selektiv pro Container (--runtime=kata-runtime)

Voraussetzungen: - Benötigt /dev/kvm → Nested Virtualization erforderlich - kata-agent im Guest-Kernel - containerd als Container-Runtime (Docker kann Kata als Runtime-Plugin nutzen)

Risiken: - Wieder Nested-Virt-Abhängigkeit - Etwas höherer RAM-Verbrauch als reine MicroVMs - Debugging: Container-Logs + VM-Logs = zwei Ebenen

Fazit: Die pragmatischste VM-basierte Lösung — minimaler Umbau des bestehenden Provisioners. Empfohlen, wenn /dev/kvm verfügbar ist.

2.4 LXC/LXD (System-Container)

Konzept: System-Container, die wie leichtgewichtige VMs funktionieren. Jeder Container hat ein eigenes Init-System, eigene Services, eigene Netzwerk-Konfiguration — aber teilt den Host-Kernel.

Status quo: - .43 (Website-Server) hat bereits lxc Binary installiert - LXD/Incus kann als Container-Manager eingesetzt werden

Funktionsweise: - Jeder Kunde erhält einen LXC System-Container - Eigenes Root-Filesystem (Ubuntu/Alpine Image) - Eigene Netzwerk-Interfaces (veth pairs, Bridge) - cgroups v2 für Ressourcenlimits - Optional: AppArmor/SELinux-Profile für zusätzliche Isolation

Bewertung:

Integration mit bestehendem Provisioner:

Aktuell:  API → dockerService.ts → Docker API → Container
Neu:      API → lxdService.ts → LXD REST-API → System-Container → Docker inside

• Neuer Service nötig (LXD hat REST-API, Node.js-Client verfügbar)
• Alternativ: OpenClaw direkt in LXC ohne Docker-Layer (einfacher)
• Templates müssen angepasst werden (LXC-Profile statt Docker-Compose)

DSGVO-Einschätzung: - Gemeinsamer Kernel ist ein Kompromiss — besser als Docker, aber keine echte VM-Isolation - Für die meisten DSGVO-Anforderungen ausreichend, wenn ergänzt durch: - Unprivileged Containers - AppArmor-Profile - Netzwerk-Segmentierung - Disk-Quotas und Verschlüsselung - Für Hochrisiko-Verarbeitung (besondere Datenkategorien) könnte ein Auditor stärkere Trennung fordern

Risiken: - Kernel-Exploits betreffen weiterhin alle Mandanten - LXC/LXD-Ökosystem ist kleiner als Docker - Canonical hat LXD kommerzialisiert; Incus (Community-Fork) ist die offene Alternative

Fazit: Beste Balance aus Isolation und Effizienz, wenn echte VM-Isolation nicht verfügbar ist. Empfohlen als pragmatische Zwischenlösung.

2.5 gVisor (runsc)

Konzept: Google’s Container-Runtime, die einen User-Space-Kernel (Sentry) zwischen Container und Host-Kernel schaltet. Fängt Syscalls ab und reimplementiert sie — Container sehen nie den echten Kernel.

Funktionsweise: - Drop-in-Replacement für runc (OCI-kompatibel) - Sentry (User-Space-Kernel) emuliert ~380 Linux Syscalls - Gofer-Prozess für Filesystem-Zugriffe - Keine Hardware-Virtualisierung nötig (kein /dev/kvm erforderlich!)

Bewertung:

Integration mit bestehendem Provisioner:

Aktuell:  API → dockerService.ts → Docker API → runc → Container
Neu:      API → dockerService.ts → Docker API → runsc → Container (gVisor)

• Kein Code-Umbau nötig! Nur Docker-Daemon-Konfiguration:

  {
    "runtimes": {
      "runsc": {
        "path": "/usr/local/bin/runsc"
      }
    }
  }

• Container starten mit --runtime=runsc

• Bestehende Docker-Compose-Templates funktionieren unverändert

OpenClaw-Kompatibilität: - Node.js: ✅ Voll unterstützt - Filesystem (SQLite, Uploads): ✅ Funktioniert über Gofer - Netzwerk (HTTP, WebSocket): ✅ Funktioniert - Docker-in-gVisor: ❌ Nicht möglich (kein verschachteltes Docker)

Risiken: - Kein eigener Kernel → DSGVO-Argumentation schwächer als bei echten VMs - Manche Linux-Features nicht implementiert (z.B. bestimmte ioctl, FUSE-Mounts) - Bei Syscall-Inkompatibilitäten: schwer zu debuggen - Google-Projekt — Community kleiner als Docker/Kubernetes

Fazit: Sofort einsetzbar, null Umbauaufwand, kein /dev/kvm nötig. Ideal als schnelle Härtung der bestehenden Docker-Isolation. Für DSGVO-Argumentation ist es eine signifikante Verbesserung gegenüber reinem Docker — der emulierte Kernel verhindert die gesamte Klasse von Kernel-Exploits.

2.6 Bare-Metal Sub-VMs beim Provider

Konzept: Statt Nested Virtualization direkt beim KI-Bunker zusätzliche VMs bestellen. Jeder Kunde (oder Kundengruppe) erhält eine eigene VM auf dem physischen Host.

Bewertung:

Integration mit bestehendem Provisioner:

Aktuell:  API → dockerService.ts → Docker API → Container (lokal)
Neu:      API → providerService.ts → KI-Bunker API → VM erstellen
          → SSH/Cloud-Init → OpenClaw installieren → Bot starten

• Neuer Service für Provider-API-Integration
• Cloud-Init oder Ansible für automatische VM-Konfiguration
• DNS/Reverse-Proxy-Management auf .43 (Control Plane)

Kostenabschätzung:

Hybrid-Modell möglich: - Standard-Kunden: Shared VM mit gVisor/LXC-Isolation - Premium-Kunden: Eigene VM (Aufpreis, bessere DSGVO-Garantie) - Enterprise-Kunden: Dedizierte Hardware

Risiken: - Abhängigkeit von Provider-Verfügbarkeit und -Preisgestaltung - Automatisierte Provisionierung nur wenn Provider API bietet - Netzwerk zwischen VMs muss gesichert werden (WireGuard) - Mehr Angriffsfläche durch mehr exponierte VMs

Fazit: Einfachste Lösung für maximale Isolation, aber teuerste. Ideal für Premium-Tier oder als langfristige Skalierungsstrategie.

3. Vergleichsmatrix

4. Entscheidungsbaum

Ist /dev/kvm in der VM verfügbar?
├── JA → Kata Containers (bester Trade-off: VM-Isolation + Docker-Kompatibilität)
│         Alternativ: Firecracker MicroVMs (wenn maximale Kontrolle gewünscht)
│
└── NEIN → Nested Virt beim Provider anfragen
           ├── Provider aktiviert es → siehe JA
           └── Provider kann/will nicht
               ├── SOFORT: gVisor installieren (zero Umbau, deutlich bessere Isolation)
               ├── MITTELFRISTIG: LXC/Incus als System-Container-Layer
               └── PREMIUM-KUNDEN: Eigene VMs beim Provider bestellen

5. Empfehlung: Phasenplan

Phase 1: Sofort umsetzbar (1-2 Tage)

→ gVisor (runsc) auf dem Bot-Server installieren

• Kein Code-Umbau erforderlich

• Installation:

  # gVisor installieren
  curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg
  echo "deb [arch=amd64 signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] https://storage.googleapis.com/gvisor/releases release main" | \
    sudo tee /etc/apt/sources.list.d/gvisor.list
  sudo apt update && sudo apt install -y runsc
  
  # Docker konfigurieren
  sudo runsc install
  sudo systemctl restart docker

• Bestehende Container mit --runtime=runsc neu starten

• Der Provisioner braucht nur eine kleine Änderung in dockerService.ts:

  // HostConfig ergänzen um:
  Runtime: 'runsc'

• Wirkung: Sofortige Kernel-Isolation durch Syscall-Interception für alle Mandanten-Container

DSGVO-Dokumentation: - TOMs (Dokument 02) aktualisieren: Trennungskontrolle um gVisor-Kernel-Emulation ergänzen - DSFA (Dokument 05) aktualisieren: Risikobewertung “Container-Breakout” von “mittel” auf “gering”

Phase 2: Kurzfristig (2-4 Wochen)

→ Nested Virtualization beim KI-Bunker klären

Anfrage an KI-Bunker: 1. Ist Nested Virtualization auf dem Host aktiviert? (kvm_intel nested=1) 2. Kann /dev/kvm im Guest exponiert werden? 3. Gibt es Performance-Garantien für Nested VMs? 4. Alternativ: Können wir einen Bare-Metal-Server (statt VM) mieten?

Wenn /dev/kvm verfügbar: → Kata Containers evaluieren und pilotieren - Installation über containerd + Kata-Packages - Einen Testkunden auf Kata-Runtime migrieren - Performance-Benchmarks durchführen

Phase 3: Mittelfristig (1-3 Monate)

→ Hybrid-Modell implementieren

• Provisioner um Tier-Auswahl erweitern

• Runtime-Selection in Template-Metadata aufnehmen:

  {
    "isolation": {
      "tier": "standard|professional|enterprise",
      "runtime": "runsc|kata-runtime|vm"
    }
  }

Phase 4: Langfristig

→ Skalierung auf dedizierte Hardware

• Bei >30 Kunden: Migration auf Bare-Metal-Server beim KI-Bunker
• Firecracker/Cloud Hypervisor mit eigenem Orchestrator
• Oder: Kubernetes + Kata Containers für automatische Skalierung

6. Kosten-Nutzen-Zusammenfassung

7. Aktualisierung der TOMs

Nach Umsetzung von Phase 1 sollte §1.4 Trennungskontrolle (TOMs, Dokument 02) wie folgt aktualisiert werden:

Ergänzung — Erweiterte Prozessisolation: - Kernel-Level-Isolation durch gVisor (runsc) Container-Runtime mit User-Space-Kernel-Emulation - Syscall-Filterung und -Reimplementierung verhindert direkte Kernel-Interaktion von Mandanten-Prozessen - Separate Sentry-Prozesse pro Mandant für unabhängige Syscall-Verarbeitung - Optionale VM-basierte Isolation (Kata Containers) für Mandanten mit erhöhtem Schutzbedarf

8. Nächste Schritte

• Sofort: gVisor auf dem Bot-Server (.45) installieren und testen
• Sofort: OpenClaw-Kompatibilität mit runsc validieren (Testcontainer)
• Diese Woche: KI-Bunker wegen Nested Virtualization / /dev/kvm kontaktieren
• Diese Woche: KI-Bunker nach Bare-Metal-Server-Optionen und Preisen fragen
• Nach Klärung: Kata Containers oder LXC/Incus pilotieren
• Bei Umsetzung: TOMs und DSFA aktualisieren

Dieses Dokument ist Teil des Qognio DSGVO-Dokumentationspakets und sollte bei jeder Architekturänderung aktualisiert werden.