メインコンテンツへスキップ

概要

Jinba Toolboxは、組織ベースの隔離を中心としたセキュリティモデルを実装しています。ToolSet、Tool、Version、Run、APIキー、Webhookなど、すべてのリソースは組織に属し、ロールベースアクセス制御(RBAC)と認証済みセッションまたはAPIキーによって保護されます。

認証

Jinba Toolboxは、それぞれ異なるアクセスパターン向けに設計された2つの認証方法をサポートしています:

セッションベース(Web)

Webコンソールで使用されます。ユーザーはJinbaAuth(テナントSSOを含むJinba共通のサインインサービス)でサインインし、コンソールはJinbaAuthのJWTをAPIに送信します。APIはこれを検証し、ユーザーの組織ロールをJinbaAuthから取得します。
  • ToolSetを管理する人間のユーザー向け
  • ドラフトコードのテスト、Versionの公開、APIキーの作成に必須
  • 組織リソースへのロールベースのアクセス

APIキー(プログラム)

SDK、AIエージェント、外部統合で使用されます。Bearerトークンとして渡します。
  • Authorization: Bearer jtb_xxxxxxxxxxxx
  • 自動化およびプログラムアクセス向け
  • 単一の組織にスコープ、Memberレベルの権限、1つのToolSet環境に紐付け

APIキーの管理

APIキーは組織にスコープされ、発行者を追跡します:
主なプロパティ:
  • 有効期限なし — キーは手動で削除するまで有効です。
  • ハッシュ化して保存 — 検証にはSHA-256ハッシュのみが使用されます。暗号化されたコピーにより、コンソールから完全なキーを再表示できます。
  • 最終使用日時が各キーに記録されます。
  • 発行者の追跡 — キーを作成したメンバーが記録されます。
  • 環境への紐付け — 各キーは、その実行で使用するToolSet環境(変数とアクティブVersion)を選択します。
キーを発行したメンバーが組織を離れても、統合の中断を避けるためキーはアクティブなまま維持されます。コンソールには「Issuer is no longer a member」の警告が表示され、OwnerまたはAdminがそのキーを削除して新しいキーを発行できます。

APIキーエンドポイント

ロールベースアクセス制御(RBAC)

ロール階層

Jinba Toolboxは2つのレベルでロールを定義しています:
組織ロールはJinbaAuthで割り当てられ、Toolboxはリクエストごとにそれを参照します。

組織ロール

権限マトリックス

組織とメンバーの管理(名前変更、削除、招待、ロール変更、メンバー削除)はJinbaAuthで行います。対応するToolbox APIルートは 403 を返します。

ロールのルール

  • ロールとオーナーシップはJinbaAuthで管理されます。
  • Memberは自分のAPIキーを作成・削除でき、組織のすべてのキーを参照できますが、他者が作成したキーを削除することはできません。
  • APIキーは、発行者のロールに関わらずMemberとして動作します。

組織ベースの隔離

Jinba Toolboxのすべてのリソースは組織にスコープされています。隔離はAPIサーバーで強制されます。組織スコープのすべてのリクエストに対して、呼び出し元のメンバーシップ(セッション)を解決するか、APIキーがリクエストされた組織に属していることを検証し、その後に初めてその組織のリソースを参照します。メンバーでない場合のリクエストには 404、権限不足には 403 が返されます。 Runレコードは呼び出し元の組織とプロバイダー組織の両方を保持します。他の組織があなたの公開Toolを実行した場合、あなたにはRunのステータスと時間は見えますが、入力、出力、ログは見えません。これらを閲覧できるのは呼び出し元の組織のみです。

Runのログ

Toolの実行はRunレコードとして、入力、出力、エラー、キャプチャされたstdout/stderrとともに追跡されます。クレジットの消費はクレジット取引として記録され、Creditsページに一覧表示されます。

Sandboxの隔離

Toolの実行は、隔離されたSandbox環境(E2BまたはDaytona)で行われます。各実行は新規のSandboxインスタンスで実行され、以下の特性を持ちます:
  • プロセスの隔離 — 各Sandboxは個別のコンテナまたはVMです。
  • Egress制御 — 組織でegressプロキシが有効な場合(JinbaAuthの組織設定)、E2BのSandboxはユーザーコードの実行前にハードニングされ、外向きトラフィックはJinbaのegressプロキシ経由にルーティングされます。プロキシの認証情報は呼び出し元に返されるすべての内容からマスクされます。この設定がない場合、Sandboxはプロバイダー既定の外向きネットワークアクセスのままです。
  • 設定可能な環境変数 — シークレットはToolSetの環境ごとに注入され、ToolSet間で共有されません。シークレット値は暗号化して保存されます。
  • 自動クリーンアップ — 実行完了またはタイムアウト後、Sandboxは直ちに終了(kill)されます。

ベストプラクティス

  • 環境ごとに異なるAPIキーを使用する(本番、ステージング、CI/CD) — キーが漏洩した場合の影響範囲を限定するためです。
  • APIキーの使用状況を監査する — 最終使用日時を定期的に確認し、不要になったキーは削除してください。
  • 最小権限のロールを割り当てる — Toolの作成・編集のみが必要な開発者にはMemberを使用してください。
  • 実行履歴を定期的に確認する — 予期しない利用パターンを検出するためです。
  • 組織間でAPIキーを共有しない — 各キーは単一の組織にスコープされています。

関連ドキュメント