> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Tenant-Verwaltung (Organisationen & Mitglieder) > AgentEye Dokumentation zur Tenant-Verwaltung (Organisationen & Mitglieder). Eine einzige AgentEye-Instanz bedient mehrere vollständig isolierte **Organisationen** (Tenants), sodass eine Installation verschiedene Teams, Geschäftsbereiche oder Kunden hosten kann, ohne dass die Daten eines Tenants für einen anderen sichtbar sind. Jede Datenzeile (Ereignisse, Auswertungen, Sitzungen, Dashboards, gespeicherte Abfragen, Alarme, API-Schlüssel und Mitglieder) gehört genau einer Organisation. Die primäre Isolation wird im Anwendungscode erzwungen: Jede Anfrage wird mit expliziten `org_id`-Prädikaten auf die jeweilige Organisation beschränkt. In ClickHouse – wo die ereignis- und auswertungsreichen Daten mit hohem Volumen liegen – wird dies durch eine strikte Engine-seitige Durchsetzung abgesichert: Jede Organisation erhält einen dedizierten, schreibgeschützten ClickHouse-Benutzer mit einer organisationsspezifischen Zeilenrichtlinie, sodass selbst nicht vertrauenswürdiges Analyse-SQL niemals die Zeilen eines anderen Tenants lesen kann. In PostgreSQL fügt Row-Level-Security eine zusätzliche Schutzschicht auf dem schreibgeschützten Abfragepfad (`/queries/run`) hinzu und begrenzt, was dieser Pfad sehen kann, selbst wenn ein Filter auf Anwendungsebene fehlen sollte. Die eigene Schreibverbindung des Servers läuft als Tabelleneigentümer und unterliegt damit demselben `org_id`-Scoping auf Anwendungsebene. Der Lebenszyklus von Tenants wird durch Operatoren gesteuert, während alles, was Mitglieder täglich tun, im Dashboard als Self-Service verfügbar bleibt. Organisationen und ihre Mitgliedschaften werden mit der **`agenteye-orgctl`**-CLI erstellt und verwaltet, die im Server-Image enthalten ist und **innerhalb des bestehenden Server-Pods** ausgeführt wird. Die Erstellung und Löschung von Tenants ist bewusst aus dem Dashboard und der HTTP-API herausgehalten: Es gibt **keine HTTP-API und keinen Dashboard-Button** für den Tenant-Lebenszyklus – der Zugriff ist daher hinter dem Cluster-/Pod-Shell-Zugang gesichert und nicht über die Anwendungsoberfläche zugänglich. Innerhalb einer Organisation arbeiten Mitglieder vollständig im Dashboard und über die API: Sie melden sich an, wechseln zwischen ihren Organisationen, verwalten ihre eigenen API-Schlüssel, erstellen Dashboards und gespeicherte Abfragen und konfigurieren Alarme für ihre Organisation. Die Trennung ist klar: Operatoren stellen Tenants und deren Mitglieder per CLI bereit und nehmen sie außer Betrieb; Mitglieder steuern alles innerhalb eines Tenants über die Benutzeroberfläche. > **Einzelne-Tenant-Installationen benötigen nichts davon.** Eine Single-Tenant-Installation läuft ohne jegliche Operator-Aktion. Alle Daten, Benutzer und Schlüssel befinden sich in einer eingebauten `default`-Organisation, die automatisch bereitgestellt wird. Dieser Leitfaden wird erst relevant, wenn Sie eine zweite Organisation hinzufügen möchten. *** ## Voraussetzungen Bevor Sie Ihre **zweite** Organisation anlegen (die eingebaute `default`-Org benötigt nichts): * **PostgreSQL 15+.** Das Org-Mitgliedschaftsschema verwendet einen `ON DELETE SET NULL`-Fremdschlüssel mit Spaltenliste, der PostgreSQL 15+ erfordert. Aktualisieren Sie PostgreSQL, bevor Sie eine zweite Organisation bereitstellen. * **Ein starkes, stabiles `ORG_CH_SECRET`.** Das ClickHouse-Passwort jeder Organisation wird als `HMAC(ORG_CH_SECRET, org_id)` abgeleitet. Ein öffentlich bekannter eingebauter Entwicklungsstandard würde öffentlich ableitbare Anmeldedaten je Organisation ergeben. `agenteye-orgctl org create` **verweigert die Ausführung, solange `ORG_CH_SECRET` nicht gesetzt oder auf dem eingebauten Entwicklungsstandard belassen wird**. Legen Sie zuerst einen eigenen Wert fest (siehe [Deployment → Umgebungsvariablen](/de/agenteye/deployment) und, auf Kubernetes, [§2.6 des Kubernetes-Leitfadens](/de/agenteye/kubernetes-deployment#26-multi-tenant-org-isolation-key-optional)). Halten Sie den Wert über alle Server-Replikate hinweg identisch und rotieren Sie ihn nicht leichtfertig; eine Rotation macht den ClickHouse-Benutzer jeder Organisation verwaist, bis beim nächsten Start eine erneute Bereitstellung erfolgt. *** ## Die CLI ausführen `agenteye-orgctl` wird im **gleichen Image wie der Server** mitgeliefert (neben `agenteye-server`). Sie müssen **keinen** separaten Pod, Job oder Deployment dafür erstellen; Sie führen es per `exec` innerhalb des bereits laufenden Server-Pods aus, damit es dasselbe `DATABASE_URL`, `CLICKHOUSE_URL` und `ORG_CH_SECRET` wie der Server verwendet. **Kubernetes:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- agenteye-orgctl ``` **Docker Compose:** ```bash theme={null} docker compose exec server agenteye-orgctl ``` Die folgenden Beispiele zeigen das bare `agenteye-orgctl ` der Kürze halber; stellen Sie jeder Zeile das für Ihre Deployment-Art passende der beiden obigen Präfixe voran. *** ## Befehlsreferenz ### Organisationen | Befehl | Funktion | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `org create --slug --name ` | Erstellt eine neue Organisation. Verweigert die Ausführung, solange `ORG_CH_SECRET` nicht gesetzt oder auf dem eingebauten Entwicklungsstandard belassen ist (setzen Sie zuerst einen eigenen Wert, siehe Voraussetzungen). Stellt den schreibgeschützten ClickHouse-Benutzer und die Zeilenrichtlinie der Organisation bereit. | | `org list` | Listet alle Organisationen auf (Slug, Name und Lebenszykluszustand). | | `org rename --slug --name ` | Ändert den Anzeigenamen einer Organisation. Der Slug (der in URLs und Schlüsseln verwendet wird) bleibt unverändert. | | `org delete --slug ` | **Soft-Delete** der Organisation und Entfernen ihres ClickHouse-Benutzers. Daten werden **beibehalten**. Dadurch wird der Zugriff entzogen und das organisationsspezifische ClickHouse-Credential freigegeben, ohne Ereignisse zu löschen. Durch Ops reversibel; sicherer erster Schritt vor einer endgültigen Bereinigung. | | `org purge --slug ` | **Unwiderrufliche Datenlöschung.** Die Organisation muss bereits `delete`d sein. Niemals für die eingebaute `default`-Org zulässig. Nur verwenden, wenn Sie sicher sind, dass die Daten des Tenants vernichtet werden sollen. | ### Mitglieder | Befehl | Funktion | | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `member add --org --email [--set ] [--add perm1,perm2] [--remove perm3] [--protected]` | Fügt ein Mitglied zu einer Organisation hinzu. Optional wird von einem eingebauten Berechtigungssatz gestartet und anschließend werden einzelne Berechtigungen hinzugefügt oder entfernt. `--protected` fixiert das Mitglied, sodass es nicht über das Dashboard entfernt oder herabgestuft werden kann (siehe unten). Das neue Mitglied erhält beim ersten Dashboard-Login ein OTP. | | `member list --org ` | Listet die Mitglieder der Organisation auf. Die Ausgabespalten sind `EMAIL`, `SET` (der eingebaute Satz, von dem das Mitglied gestartet ist, oder `-`), `PROT` (ob das Mitglied geschützt ist) und `PERMISSIONS` (die effektiven Berechtigungen). Eine E-Mail mit einem nachgestellten `*` kennzeichnet einen Instanz-Admin; dieser hat Zugriff auf alle Organisationen. | | `member update --org --email [--set ...] [--add ...] [--remove ...] [--protected \| --unprotect]` | Ändert die Berechtigungen eines Mitglieds und/oder dessen Schutzstatus. `--set` ersetzt durch einen eingebauten Satz; `--add` / `--remove` passen einzelne Berechtigungen an; `--protected` / `--unprotect` schalten den Schutz um. Wird nur `--protected`/`--unprotect` übergeben (ohne Grant-Flags), wird ausschließlich der Schutz geändert und bestehende Berechtigungen bleiben unberührt. | | `member remove --org --email ` | Entfernt ein Mitglied aus der Organisation. Verweigert, wenn das Mitglied geschützt ist; heben Sie zuerst den Schutz mit `--unprotect` auf. (Eine Person kann Mitglied mehrerer Organisationen sein; dies betrifft nur die genannte Organisation.) | Eine Person kann Mitglied mehrerer Organisationen mit **unterschiedlichen** Berechtigungen sein, z. B. Admin in einer Organisation und nur lesend in einer anderen. Jede Mitgliedschaft wird unabhängig pro Organisation verwaltet: Das Gewähren oder Ändern von Berechtigungen in einer Organisation hat keinen Einfluss auf die Mitgliedschaft in einer anderen. ### Geschützte Mitglieder (ein unentfernbarer Org-Admin) Der Schutz stellt sicher, dass sich eine Organisation nie versehentlich aus der Selbstverwaltung aussperren kann. Standardmäßig können die Admins einer Organisation sich gegenseitig über die Self-Service-Benutzerseite im Dashboard hinzufügen und entfernen – was dazu führen könnte, dass der letzte Admin entfernt wird und niemand die Organisation mehr verwalten kann. Die Benutzerseite: eine Karte pro Dashboard-Benutzer mit E-Mail, gewährten Berechtigungen und Bearbeitungs-/Deaktivierungssteuerelementen Um dies zu verhindern, markieren Sie ein Mitglied als **geschützt**: ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member add --org acme --email owner@acme.example --set admin --protected ``` Ein geschütztes Mitglied **kann nicht über das Dashboard entfernt oder herabgestuft werden**; diese Aktionen geben einen Fehler zurück. Nur ein Operator kann es über diese CLI ändern: Führen Sie zuerst `member update --org acme --email owner@acme.example --unprotect` aus, dann entfernen oder stufen Sie herab. Dies garantiert, dass jede Organisation mindestens einen Admin behält, den ihre eigenen Mitglieder nicht aussperren können, während die Tenant-Kontrolle ausschließlich beim Operator verbleibt. Der Schutz gilt **pro Organisation**; der Schutz einer Person in einer Organisation hat keinen Einfluss auf ihre Mitgliedschaft in einer anderen. ### Eingebaute Berechtigungssätze `--set` akzeptiert einen von drei eingebauten Sätzen, die pro Organisation angewendet werden: | Satz | Vorgesehen für | | ----------- | -------------------------------------------------------------------------------------------------------------------------------- | | `admin` | Vollständiger Zugriff innerhalb der Organisation, einschließlich der Verwaltung der API-Schlüssel und Benutzer der Organisation. | | `standard` | Tägliche Nutzung: Abfragen lesen und ausführen, Dashboards erstellen, Incidents bestätigen. | | `read-only` | Nur-Lesen-Zugriff auf die Daten und Dashboards der Organisation. | Starten Sie mit `--set` von einem Satz aus und passen Sie ihn dann mit `--add` / `--remove` und den einzelnen Berechtigungs-Tokens aus [API-Schlüssel](/de/agenteye/api-keys) an. Die Berechtigungs-Tokens sind identisch mit denen, die für API-Schlüssel verwendet werden. *** ## Ausführliches Beispiel Einen neuen `acme`-Tenant bereitstellen, seinen ersten Admin hinzufügen, ihm ermöglichen, einen Schlüssel zu erstellen, und die Organisation anschließend außer Betrieb nehmen. **1. Organisation erstellen** (`ORG_CH_SECRET` muss bereits auf einen starken, stabilen Wert gesetzt sein, nicht ungesetzt oder auf dem eingebauten Entwicklungsstandard): ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org create --slug acme --name "Acme Corp" ``` **2. Das erste Mitglied als Org-Admin hinzufügen:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member add --org acme --email alice@acme.example --set admin ``` Alice erhält beim ersten Anmelden im Dashboard ein OTP. Danach arbeitet sie vollständig in der Benutzeroberfläche unter dem URL-Präfix ihrer Organisation (z. B. `/acme/sessions`). **3. Einen organisationsspezifischen API-Schlüssel erstellen (im Dashboard):** Der Operator erstellt organisationsspezifische Datenschlüssel **nicht** über die CLI. Alice (oder ein anderes Org-Mitglied mit `keys:create`) erstellt Collector-/Dashboard-Schlüssel für die `acme`-Organisation über die **Schlüssel**-Seite im Dashboard. Jeder von ihr erstellte Schlüssel wird automatisch mit ihrer Organisation gestempelt und kann ausschließlich die Daten von `acme` lesen oder schreiben. Siehe [API-Schlüssel](/de/agenteye/api-keys). **4. Ein Mitglied nachträglich anpassen:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member update --org acme --email alice@acme.example --add alerts:write kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member list --org acme ``` **5. Organisation soft-löschen** (entzieht Zugriff + entfernt den ClickHouse-Benutzer; Daten werden beibehalten): ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org delete --slug acme ``` **6. Organisation bereinigen** (unwiderruflich; nur nach einem Soft-Delete; niemals die `default`-Org): ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org purge --slug acme ``` Ersetzen Sie bei Docker Compose jeden `kubectl -n agenteye exec deploy/server --`-Präfix durch `docker compose exec server`. *** ## Aufgabenteilung Alles, was ein Org-Mitglied täglich benötigt, steht als Self-Service im Dashboard und in der API zur Verfügung und ist automatisch auf die aktuelle Organisation beschränkt: * **Organisationsspezifische API-Schlüssel** werden von Org-Mitgliedern im Dashboard (oder über die Keys-API mit einem Schlüssel, der `keys:create` trägt) erstellt und verwaltet. Die CLI erstellt **keine** Datenschlüssel. Siehe [API-Schlüssel](/de/agenteye/api-keys). * **Organisations-Wechsel** ist in das Dashboard integriert; Mitglieder wechseln über den Org-Umschalter zwischen ihren Organisationen, und organisations-spezifische Seiten befinden sich unter `//…`. * **Dashboards, gespeicherte Abfragen, Alarme und die gesamte Datennutzung** finden vollständig in der Benutzeroberfläche und API statt, begrenzt auf die aktuelle Organisation des Mitglieds. Der Operator nutzt `agenteye-orgctl` ausschließlich für den Org- und Mitglieds-**Lebenszyklus**: Organisation erstellen / umbenennen / löschen / bereinigen sowie Mitglieder hinzufügen / auflisten / aktualisieren / entfernen. *** ## Siehe auch * [Deployment](/de/agenteye/deployment): `ORG_CH_SECRET` und die übrigen Server-Umgebungsvariablen. * [Kubernetes-Deployment](/de/agenteye/kubernetes-deployment): §2.6 erstellt das `agenteye-org-ch-secret`-Secret vor Ihrer ersten Multi-Tenant-Organisation. * [API-Schlüssel](/de/agenteye/api-keys): Das organisations-spezifische Schlüsselmodell und die von `--add` / `--remove` verwendeten Berechtigungs-Tokens. * [Fehlerbehebung](/de/agenteye/troubleshooting): Probleme bei der Multi-Tenant-Bereitstellung und ClickHouse-Isolation.