メインコンテンツへスキップ
単一の AgentEye デプロイメントで、複数の完全に分離された組織（テナント）を提供します。これにより、1つのインスタンスで異なるチーム、事業部門、または顧客をホストしながら、あるテナントのデータが別のテナントに公開されることを防ぎます。すべてのデータ行（イベント、評価、セッション、ダッシュボード、保存済みクエリ、アラート、APIキー、メンバー）は、必ず1つの組織に属します。主要な分離はアプリケーションコードで強制されます。すべてのリクエストは、明示的な org_id 述語によって対象の組織にスコープされます。大量のイベントと評価が格納される ClickHouse では、これはエンジンレベルの強力な強制によって裏付けられています。各組織は専用の読み取り専用 ClickHouse ユーザーと組織ごとの行ポリシーを持つため、信頼されていない分析 SQL でも別テナントの行を読み取ることはできません。PostgreSQL では、行レベルセキュリティが読み取り専用クエリパス（/queries/run）に多層防御を追加し、アプリケーションレベルのフィルターが欠落していた場合でも、そのパスが参照できるデータを制限します。サーバー自身の書き込みコネクションはテーブルオーナーとして実行されるため、アプリケーションレベルの org_id スコープを通じて動作します。 テナントのライフサイクルはオペレーターが管理し、メンバーが日常的に行うすべての操作はダッシュボードでセルフサービスとして利用できます。組織とそのメンバーシップは agenteye-orgctl CLIを使用して作成・管理します。このCLIはサーバーイメージに同梱されており、既存のサーバーポッド内で実行します。テナントの作成と削除は意図的にダッシュボードとHTTP APIから除外されています。テナントのライフサイクルにはHTTPエンドポイントもダッシュボードのボタンも存在しません。そのため、アプリケーションの表面からではなく、クラスター/ポッドのシェルアクセスによってのみ操作できます。 組織内では、メンバーはダッシュボードとAPIだけで作業します。サインイン、所属する組織の切り替え、自分のAPIキーの管理、ダッシュボードや保存済みクエリの構築、および組織のアラート設定などが行えます。役割分担は明確です。オペレーターはCLIを通じてテナントとメンバーのプロビジョニング・廃止を行い、メンバーはUIを通じてテナント内のすべてを操作します。
シングルテナント構成ではこの手順は不要です。 シングルテナントのインストールは、オペレーターの操作なしに動作します。すべてのデータ、ユーザー、キーは、自動的にプロビジョニングされる組み込みの default 組織に格納されます。このガイドが必要になるのは、2つ目の組織を追加する場合のみです。

​
前提条件

2つ目の組織を作成する前に（組み込みの default 組織には何も必要ありません）:
  • PostgreSQL 15以降。 組織メンバーシップのスキーマは、PostgreSQL 15以降が必要な列リスト形式の ON DELETE SET NULL 外部キーを使用します。2つ目の組織をプロビジョニングする前に PostgreSQL をアップグレードしてください。
  • 強力で安定した ORG_CH_SECRET。 各組織の ClickHouse パスワードは HMAC(ORG_CH_SECRET, org_id) として導出されます。そのため、公知の組み込み開発用デフォルト値を使用すると、組織ごとの認証情報が外部から推測可能になります。agenteye-orgctl org create は ORG_CH_SECRET が未設定または組み込みの開発用デフォルト値のままの場合、実行を拒否します。事前に独自の値を設定してください（デプロイメント → 環境変数 および Kubernetes の場合は Kubernetes ガイドのセクション 2.6 を参照してください）。すべてのサーバーレプリカで同一の値を使用し、気軽にローテーションしないでください。ローテーションすると、次回の起動で再プロビジョニングされるまで、すべての組織の ClickHouse ユーザーが孤立状態になります。

​
CLIの実行方法

agenteye-orgctl は サーバーと同じイメージ（agenteye-server の隣）に同梱されています。専用のポッド、Job、Deployment はデプロイしません。既に実行中のサーバーポッド内で exec して使用するため、サーバーが使用している DATABASE_URL、CLICKHOUSE_URL、ORG_CH_SECRET と同じ値が読み込まれます。 Kubernetes:
Docker Compose:
以下の例では簡潔さのために agenteye-orgctl <args> のみ記載しています。実際には、デプロイメント環境に応じて上記いずれかの行を先頭に付けてください。

​
コマンドリファレンス

​
組織

コマンド内容
org create --slug <slug> --name <name>新しい組織を作成します。ORG_CH_SECRET が未設定または組み込みの開発用デフォルト値のままの場合は実行を拒否します（前提条件を参照して事前に独自の値を設定してください）。組織の読み取り専用 ClickHouse ユーザーと行ポリシーをプロビジョニングします。
org listすべての組織（スラッグ、名前、ライフサイクル状態）を一覧表示します。
org rename --slug <slug> --name <new name>組織の表示名を変更します。スラッグ（URLとキーで使用）は変更されません。
org delete --slug <slug>組織をソフトデリートし、その ClickHouse ユーザーを削除します。データは保持されます。アクセスを無効化し、組織ごとの ClickHouse 認証情報を解放しますが、イベントは削除しません。オペレーターによって元に戻すことができ、パージ前の安全な最初のステップです。
org purge --slug <slug>不可逆的なデータ削除。 組織は事前に delete されている必要があります。組み込みの default 組織には絶対に実行できません。テナントのデータを確実に破棄する場合にのみ使用してください。

​
メンバー

コマンド内容
member add --org <slug> --email <email> [--set <permission-set>] [--add perm1,perm2] [--remove perm3] [--protected]組織にメンバーを追加します。オプションで組み込みの権限セットをベースにして、個別の権限を追加/削除できます。--protected を指定すると、ダッシュボードからメンバーを削除またはデモートできなくなります（後述）。新しいメンバーは、最初のダッシュボードログイン時にOTPを受け取ります。
member list --org <slug>組織のメンバーを一覧表示します。出力列は EMAIL、SET（メンバーが使用した組み込みセット、または -）、PROT（メンバーが保護されているかどうか）、PERMISSIONS（有効な権限）です。末尾に * が付いたメールアドレスはインスタンス管理者を示し、すべての組織にアクセスできます。
member update --org <slug> --email <email> [--set ...] [--add ...] [--remove ...] [--protected | --unprotect]メンバーの権限や保護フラグを変更します。--set は組み込みセットで置き換え、--add / --remove は個別の権限を調整し、--protected / --unprotect は保護を切り替えます。付与フラグなしで --protected/--unprotect のみを指定した場合、保護のみが変更され、既存の権限はそのまま維持されます。
member remove --org <slug> --email <email>組織からメンバーを削除します。メンバーが保護されている場合は拒否されます。先に --unprotect してください。（1人が複数の組織のメンバーになれますが、これは指定した組織のみに影響します。）
1人が複数の組織のメンバーになることができ、それぞれで異なる権限を持てます。例えば、ある組織では管理者、別の組織では読み取り専用といった設定が可能です。各メンバーシップは組織ごとに独立して管理されます。ある組織でのメンバーの権限変更は、他の組織でのメンバーシップには影響しません。

​
保護メンバー（削除不可能な組織管理者）

保護機能により、組織が誤ってセルフ管理から締め出されることを防ぎます。デフォルトでは、組織内の管理者はダッシュボードのセルフサービスのユーザーページから互いを追加・削除できるため、最後の管理者を削除して組織を管理できない状態にしてしまう可能性があります。 ユーザーページ：ダッシュボードユーザーごとにカードが表示され、メールアドレス、付与された権限、編集/無効化コントロールが含まれます これを防ぐために、1人のメンバーを保護としてマークします:
保護されたメンバーはダッシュボードから削除またはデモートできません。そのような操作はエラーになります。変更できるのはオペレーターのみで、このCLIからのみ操作可能です。まず member update --org acme --email owner@acme.example --unprotect を実行してから、削除またはデモートしてください。これにより、すべての組織が少なくとも1人の管理者を維持し、組織のメンバー自身がその管理者を締め出せないようになります。また、テナントの管理権限はオペレーターのみに維持されます。保護は組織ごとに設定されます。ある組織で誰かを保護しても、別の組織でのメンバーシップには影響しません。

​
組み込み権限セット

--set は、組織ごとに適用される3つの組み込みセットのいずれかを受け付けます:
セット対象
admin組織内でのフルアクセス。組織のAPIキーとユーザーの管理を含みます。
standard日常的な使用：クエリの読み取りと実行、ダッシュボードの構築、インシデントの承認。
read-only組織のデータとダッシュボードへの閲覧のみのアクセス。
--set でセットを指定した後、APIキー に記載されている個別の権限トークンを使用して --add / --remove で細かく調整できます。権限トークン自体はAPIキーに使用されるものと同一です。

​
実践例

新しい acme テナントをプロビジョニングし、最初の管理者を追加して、キーを作成させた後、組織を廃止します。 1. 組織を作成する（ORG_CH_SECRET は事前に強力で安定した値に設定されている必要があります。未設定または組み込みの開発用デフォルト値のままにしないでください）:
2. 最初のメンバーを組織管理者として追加する:
Alice はダッシュボードに初めてサインインするときにOTPを受け取ります。それ以降は、組織のURLプレフィックス（例: /acme/sessions）のもとで、UIでのみ作業します。 3. 組織ごとのAPIキーを作成する（ダッシュボードにて）: オペレーターはCLIから組織ごとのデータキーを作成しません。Alice（または keys:create 権限を持つ組織メンバー）が、ダッシュボードのキーページから acme 組織のコレクター/ダッシュボードキーを作成します。作成されたすべてのキーは自動的に組織と紐付けられ、acme のデータの読み書きのみが可能です。APIキー を参照してください。 4. 後でメンバーを変更する:
5. 組織をソフトデリートする（アクセスを無効化し ClickHouse ユーザーを削除；データは保持）:
6. 組織をパージする（不可逆；ソフトデリート後のみ；default 組織は不可）:
Docker Compose の場合は、各コマンドの kubectl -n agenteye exec deploy/server -- プレフィックスを docker compose exec server に置き換えてください。

​
責任の分担

組織メンバーが日常的に必要とするすべての操作は、ダッシュボードとAPIでセルフサービスとして利用でき、現在の組織に自動的にスコープされます:
  • 組織ごとのAPIキーは、ダッシュボード（または keys:create を持つキーを使用したキーAPIを通じて）で組織メンバーが作成・管理します。CLIはデータキーを作成しません。APIキー を参照してください。
  • 組織の切り替えはダッシュボードに組み込まれており、メンバーは組織スイッチャーから所属する組織を切り替えることができます。組織スコープのページは /<org-slug>/… 以下に存在します。
  • ダッシュボード、保存済みクエリ、アラート、およびすべてのデータ利用は、UIとAPIで完結し、メンバーの現在の組織にスコープされます。
オペレーターは agenteye-orgctl を使用して、組織とメンバーのライフサイクルのみを管理します。つまり、組織の作成/名前変更/削除/パージ、およびメンバーの追加/一覧表示/更新/削除です。

​
関連情報

  • デプロイメント: ORG_CH_SECRET とその他のサーバー環境変数。
  • Kubernetes デプロイメント: セクション 2.6 では、最初のマルチテナント組織の前に agenteye-org-ch-secret シークレットを作成します。
  • APIキー: 組織ごとのキーモデルと、--add / --remove で使用される権限トークン。
  • トラブルシューティング: マルチテナントのプロビジョニングと ClickHouse 分離に関する問題。