Zugriffskontrolle¶

Zugriffskontrolle

Rollen- und Berechtigungsmodell der Inovetra AI Platform. Dieses Dokument beschreibt die verschiedenen Zugriffsebenen, Authentifizierungsmethoden und Best Practices für die Zugriffsverwaltung.

Zugriffsebenen¶

Ebene	Zugriff	Authentifizierung
SSH (VM)	Nur Inovetra / Admin	SSH-Key
Kubernetes API (6443)	kubectl über VPN	kubeconfig
Customer Portal	Plattform-Administratoren	JWT (Benutzername/Passwort oder SSO)
LibreChat	Endbenutzer	LibreChat-eigene Authentifizierung
API (programmatisch)	Integrationen	API-Key oder JWT

Rollen im Customer Portal¶

Rolle	Berechtigungen
Admin	Volle Verwaltung: Benutzer, Konfiguration, Updates, Monitoring, RAG, Connectors
RAG Manager	Verwaltung von RAG-Dokumenten und Zugriffsgruppen
User	Basis-Zugriff ohne administrative Funktionen

Empfehlung

Mindestens zwei Admin-Accounts einrichten, um bei Ausfall eines Accounts weiterhin Zugriff zu haben.

Zugriffsgruppen (RAG)¶

RAG-Dokumente können Zugriffsgruppen zugeordnet werden, um den Zugriff auf sensible Informationen einzuschränken:

Benutzer sehen nur Dokumente, die einer ihrer Zugriffsgruppen zugeordnet sind
Dokumente ohne Zugriffsgruppe sind für alle Benutzer mit mindestens einer Gruppe sichtbar
Benutzer ohne jegliche Gruppenzuordnung sowie Anfragen ohne auflösbaren User-Kontext erhalten seit Helm Chart 0.73.3 keine RAG-Treffer mehr (Deny-All) — vorher sahen sie alle Dokumente mit leerem access_groups-Feld
Konfiguration über Customer Portal → Zugriffsgruppen
Zuweisung der Benutzer zu Gruppen über die Benutzerverwaltung
Änderungen an Dokument- oder Konnektor-Gruppen propagieren seit 0.73.3 automatisch auf bereits indexierte Chunks und Inventareinträge — ein Re-Sync ist nicht nötig

API-Key-Authentifizierung¶

Für programmatischen Zugriff (z.B. Chat Widget, externe Integrationen):

Verwaltung über Customer Portal → API-Keys
Separate Keys pro Integration empfohlen
Keys können jederzeit widerrufen werden
Jeder Key hat einen beschreibenden Namen zur Identifikation

Wichtig

API-Keys gewähren Zugriff auf die Chat-Funktionalität. Sie sollten nicht im Quellcode oder in öffentlichen Repositories gespeichert werden.

Interne Service-Authentifizierung: OS Manager (ab 0.81.20)¶

Der OS Manager ist der privilegierteste Service (Host-Root, DaemonSet). Seine API ist primär über eine NetworkPolicy geschützt, die ausschließlich Zugriffe der Customer API erlaubt. Mit Helm Chart 0.81.20 kommt als zweite Verteidigungslinie ein Shared-Secret-Header zurück:

Aspekt	Wert
Header	`X-OS-Manager-Key`
Secret	`inovetra-os-manager-auth` (K8s Secret, als `OS_MANAGER_KEY` eingeblendet)
Modus	`OS_MANAGER_AUTH_MODE` = `off` \| `soft` \| `enforce`
Standard (aktuell)	`soft` — fehlende/falsche Keys werden nur geloggt, nicht blockiert

Geplanter Übergang zu enforce

Der Soft-Mode erlaubt eine risikofreie Einführung. Erst nachdem ein sauberer Update-Zyklus bestätigt hat, dass die Customer API durchgängig einen gültigen Header sendet, sollte auf enforce umgestellt werden (OS_MANAGER_AUTH_MODE=enforce). Im enforce-Modus verweigert der OS Manager den Start, wenn kein Schlüssel hinterlegt ist — das verhindert eine versehentliche Selbst-Aussperrung. Health-Probe-Pfade (/health) bleiben immer offen.

Zusätzlich härtet 0.81.20 den OS Manager über strengere Validierung von Logrotate-/journald-Werten und eine zusätzliche Sperre (MUTATION_LOCK) auf /updates/apply und /reboot/schedule, um Interferenzen mit laufenden Helm-Upgrades zu verhindern.

Best Practices¶

SSO aktivieren für alle Benutzer (siehe SSO-Einrichtung)
Starke Passwörter erzwingen (mindestens 12 Zeichen, Sonderzeichen)
API-Keys regelmäßig rotieren — insbesondere bei Personalwechsel
SSH-Zugang nur per Key — Passwort-Login auf der VM deaktivieren
Nicht benötigte Admin-Accounts deaktivieren — regelmäßig prüfen
Zugriffsgruppen nutzen — sensible RAG-Dokumente nur berechtigten Benutzern zugänglich machen
OS-Manager-Auth nach einem stabilen Update-Zyklus auf enforce umstellen