Files
AI-Profile-Router/docs/SECURITY.md
T

3.8 KiB

Sicherheitsmodell

Netzgrenze

  • Open WebUI und Router veröffentlichen keinerlei Host-Ports.
  • Ein dedizierter WireGuard-Container stellt OpenWebUI, Router und die Werkzeugdienste direkt auf seiner VPN-Adresse bereit. Die verbindliche Portmatrix steht in VPN_SERVICE_PORTS.md.
  • Die egressfähigen Docker-Netze verwenden eigene Routingtabellen.
  • Heimnetz- und optionaler Internetverkehr laufen über WireGuard.
  • Die Tabellen zeigen ausschließlich zum Gateway-Container und besitzen keine Route über das Standortgateway. Das ist der Fail-Closed-Mechanismus.
  • Der Host ist kein Router zwischen Universitäts- und Heimnetz.

Da keine KI-Ports publiziert werden, kann Docker die Host-Firewall an dieser Stelle nicht umgehen. SSH bleibt davon getrennt und schlüsselbasiert auf der physischen Schnittstelle erreichbar.

Containergrenzen

  • llama.cpp: read-only, keine Capabilities, Modelle read-only, keine Ports.
  • Router: unprivilegierter Benutzer, kein Docker-Socket, feste API-Oberfläche.
  • Profile Controller: einzige Socket-Ausnahme; feste Profile und nur List/Start/Stop, keine frei wählbaren Images, Befehle oder Mounts.
  • Open WebUI: einziges persistentes Chat-Volume.
  • MCP-Fachcontainer: intern verbunden und über feste WireGuard-Ports direkt für OpenWebUI, Pi, Hermes und andere Heim-VPN-Clients erreichbar.
  • TinySearch/SearXNG: intern, Suchanfragen ohne Chatverlauf.

llama.cpp bekommt weder MCP-Konfiguration noch HA-, ARR- oder Unraid-Secrets. Open WebUI kann weiterhin die internen MCP-Namen verwenden. Andere Clients nutzen ohne zusätzliches Gateway die festen MCP-Ports der WireGuard-Adresse. Authentisierung zu den Zielsystemen findet im jeweiligen Fachcontainer statt.

Ein Docker-Socket bleibt grundsätzlich privilegiert. Der Controller reduziert die erreichbare Funktion stark, ersetzt aber keine zusätzliche Socket-Proxy- Sandbox. Er ist klein, testbar und nicht von Clients direkt erreichbar.

Secrets und private Daten

  • Keine Secrets in Git, Prompts, MCP-Schemas, Logs oder Screenshots.
  • Installer-Konfiguration und /etc/mike-ai/* haben restriktive Rechte.
  • Router-, Controller- und WebUI-Schlüssel sind getrennt und zufällig.
  • Das Modell bekommt keine Schlüsselwerte zurück; spätere Integrationen nutzen lokale Broker/Environment-Dateien.
  • Open-WebUI-Volume kann Chats enthalten und wird nur verschlüsselt gesichert.

Werkzeugprofile

Modus Erlaubte Werkzeuge
Standard lokale Websuche, harmlose Hilfsfunktionen
Home Assistant eigener begrenzter HA-MCP
ARR Sonarr/Radarr, zuerst read-only
Unraid Diagnose Status und eng begrenzte Logs
Administration Vorschau, Approval-Ticket, Verifikation

Für die Athena-Plattform existiert genau ein Operator-MCP. Seine unprivilegierte Fassade sieht nur einen lokalen Unix-Socket; ein rootseitiger Executor besitzt die für Repository, Docker, Modelle, Git und Recovery notwendigen Rechte. Neben strukturierten Operationen bietet er ein breites, ausgabebegrenztes Terminal für neue Aufgaben, einschließlich SSH zu konfigurierten Zielsystemen. Serverseitig gesperrt bleiben Strombefehle sowie Änderungen an Athenas SSH, LAN, WireGuard, Firewall, Boot, Kernel, Mounts und Partitionen. Diese Grenze schützt die Erreichbarkeit des physisch entfernten Hosts.

Schreibaktionen

Persistente oder destruktive Änderungen folgen immer: Bestandsaufnahme, exakte Vorschau, an die Vorschau gebundene Freigabe, unveränderte Ausführung, anschließende Verifikation.

Vor jedem Push

  • Private-Key-, Token-, Passwort- und API-Key-Muster suchen.
  • Keine .env, Zertifikate, Logs, Bilder, Audio oder Modelle einchecken.
  • Beispiele enthalten nur Platzhalter; interne Hostnamen nur wenn bewusst.
  • Änderungen am Controller und Netzwerkguard mit Tests und Review versehen.