Zum Inhalt

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 Administratoren und RAG-Manager mit Freigabe JWT (Benutzername/Passwort oder SSO)
LibreChat Endbenutzer LibreChat-eigene Authentifizierung
Interne Dienste Nur plattformintern, nicht von außen erreichbar Gegenseitige Dienst-Authentifizierung (siehe unten)

Rollen im Customer Portal

Rolle Berechtigungen
Admin Volle Verwaltung: Benutzer, Konfiguration, Updates, Monitoring, RAG, Connectors
RAG Manager Verwaltung von RAG-Dokumenten und Zugriffsgruppen (Benutzer der eigenen Gruppen)
User Nur Chat (LibreChat), kein Zugriff auf das Customer Portal

Das Customer Portal steht nur den Rollen Admin und RAG Manager offen, und nur mit erteilter Freigabe. Benutzer mit der Rolle User (etwa nach einer Anmeldung per SSO) sehen nach dem Login den Hinweis, dass sie keinen Zugriff auf das Portal haben; den Chat nutzen sie unverändert. Ab Version 0.83.18 prüft die Plattform die Portal-Rolle auch serverseitig für alle Portal-Bereiche, einschließlich Konnektoren, Benachrichtigungen und Zugriffsgruppen.

Benutzerdaten ändern nur Administratoren (ab Version 0.83.18)

  • Kontodaten wie E-Mail-Adresse, Benutzername, Rolle und Status ändert ausschließlich ein Admin in der Benutzerverwaltung. Benutzer können ihr eigenes Konto nicht mehr selbst ändern.
  • Bei Konten aus SSO (Microsoft Entra ID, LDAP/AD) ist die E-Mail-Adresse nicht änderbar, auch nicht für Admins. Sie wird vom Identity Provider verwaltet; eine Änderung erfolgt dort.

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

Authentifizierung zwischen internen Diensten

Die internen Dienste der Plattform (Chat, Dokumentenverarbeitung, Konnektoren, Customer Portal) weisen sich untereinander mit einem gemeinsamen Dienstschlüssel aus. Der Schlüssel wird bei der Installation bzw. beim Update auf Version 0.83.18 automatisch erzeugt und bei weiteren Updates beibehalten; eine manuelle Pflege ist nicht nötig.

  • Seit Version 0.83.19 werden Aufrufe ohne gültigen Schlüssel abgelehnt (Version 0.83.18 hatte sie nur protokolliert). Benutzerrechte und Zugriffsgruppen übernimmt die Dokumentenverarbeitung nur noch von Diensten mit gültigem Schlüssel.
  • Die Dokumentenverarbeitung ist von außen nur für die Fortschrittsanzeige beim Upload und den Dokument-Viewer erreichbar; alles andere nur plattformintern. Beide sind zusätzlich geschützt: Der Dokument-Viewer über einen signierten Link, die Fortschrittsanzeige seit 0.83.19 über eine kurzlebige Berechtigung, die das Customer Portal für jeden Upload-Vorgang anfordert.

Keine API-Keys im Customer Portal

Das Customer Portal bietet keine Verwaltung von API-Keys für externe Integrationen.

Interne Service-Authentifizierung: OS Manager (ab 0.81.20)

Der OS Manager ist der privilegierteste Service (Host-Root, DaemonSet). Seine API nimmt nur Aufrufe mit einem gültigen Schlüssel im Header X-OS-Manager-Key an. Den Schlüssel kennt außer ihm nur die Customer API:

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 enforce seit Helm Chart 0.83.9: Aufrufe ohne gültigen Schlüssel werden mit 401 abgewiesen. Davor soft (nur protokolliert).

Health-Check bleibt offen

Nur /health ist ohne Schlüssel erreichbar, damit Kubernetes den Dienst überwachen kann. Fehlt der Schlüssel im Modus enforce, startet der OS Manager nicht. Der Schlüssel wird bei der Installation erzeugt und bei Updates beibehalten; eine manuelle Pflege ist nicht nötig.

Prüfen lässt sich die Einstellung direkt auf der VM:

kubectl get ds inovetra-os-manager -n inovetra-platform \
  -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="OS_MANAGER_AUTH_MODE")].value}'; echo
# Erwartet: enforce

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)
  • 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 auf enforce belassen (Standard seit Helm Chart 0.83.9) — siehe oben

Verwandte Seiten