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 eingebautedefault-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 alsHMAC(ORG_CH_SECRET, org_id)abgeleitet. Ein öffentlich bekannter eingebauter Entwicklungsstandard würde öffentlich ableitbare Anmeldedaten je Organisation ergeben.agenteye-orgctl org createverweigert die Ausführung, solangeORG_CH_SECRETnicht gesetzt oder auf dem eingebauten Entwicklungsstandard belassen wird. Legen Sie zuerst einen eigenen Wert fest (siehe Deployment → Umgebungsvariablen und, auf Kubernetes, §2.6 des Kubernetes-Leitfadens). 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:
agenteye-orgctl <args> 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 <slug> --name <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 <slug> --name <new name> | Ändert den Anzeigenamen einer Organisation. Der Slug (der in URLs und Schlüsseln verwendet wird) bleibt unverändert. |
org delete --slug <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 <slug> | Unwiderrufliche Datenlöschung. Die Organisation muss bereits deleted 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 <slug> --email <email> [--set <permission-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 <slug> | 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 <slug> --email <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 <slug> --email <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.) |
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.
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. |
--set von einem Satz aus und passen Sie ihn dann mit --add / --remove und den einzelnen Berechtigungs-Tokens aus API-Schlüssel an. Die Berechtigungs-Tokens sind identisch mit denen, die für API-Schlüssel verwendet werden.
Ausführliches Beispiel
Einen neuenacme-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):
/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.
4. Ein Mitglied nachträglich anpassen:
default-Org):
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:createträgt) erstellt und verwaltet. Die CLI erstellt keine Datenschlüssel. Siehe API-Schlüssel. - Organisations-Wechsel ist in das Dashboard integriert; Mitglieder wechseln über den Org-Umschalter zwischen ihren Organisationen, und organisations-spezifische Seiten befinden sich unter
/<org-slug>/…. - 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.
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:
ORG_CH_SECRETund die übrigen Server-Umgebungsvariablen. - Kubernetes-Deployment: §2.6 erstellt das
agenteye-org-ch-secret-Secret vor Ihrer ersten Multi-Tenant-Organisation. - API-Schlüssel: Das organisations-spezifische Schlüsselmodell und die von
--add/--removeverwendeten Berechtigungs-Tokens. - Fehlerbehebung: Probleme bei der Multi-Tenant-Bereitstellung und ClickHouse-Isolation.