アイデンティティ フェデレーションは、Multi-tenant Cloud、専用クラウド、セルフマネージドでプレビューとして利用できます。利用には Enterprise ライセンスが必須です。詳細やサポートについては、担当の AISE またはサポートにお問い合わせください。
このドキュメントでは、「アイデンティティプロバイダ」と「JWT issuer」を同じ意味で使用しています。この機能においては、どちらも同じものを指します。
JWT issuer を設定する
ユーザーが JWT で認証できるようにするには、事前に組織管理者が W&B 組織と一般公開されている JWT issuer との間でフェデレーションを設定する必要があります。- 組織のダッシュボードで Settings タブにアクセスします。
- Authentication オプションで、Set up JWT Issuer をクリックします。
- テキストボックスに JWT issuer の URL を入力し、Create をクリックします。
${ISSUER_URL}/.well-known/openid-configuration のパスにある OIDC ディスカバリードキュメントを自動的に検索します。次に、ディスカバリードキュメントを基に、該当する URL にある JSON Web Key Set (JWKS) を特定します。W&B は JWKS を使用して JWT をリアルタイムで検証し、該当するアイデンティティプロバイダによって発行されたものであることを確認します。
この手順が完了すると、W&B 組織は JWT issuer とフェデレーションされます。以降、組織内のユーザーは、そのプロバイダーが発行した JWT を使用して W&B で認証できるようになります。
JWT を使用して W&B にアクセスする
組織管理者が JWT issuer を設定すると、ユーザーはそのアイデンティティプロバイダが発行した JWT を使用して W&B プロジェクトにアクセスできるようになります。JWT の使用方法は次のとおりです。- 組織で利用可能な方法のいずれかで、アイデンティティプロバイダにサインインします。プロバイダーによっては API や SDK を使用して自動的にアクセスできますが、該当する UI からしかアクセスできないものもあります。詳細については、W&B の組織管理者または JWT issuer の所有者にお問い合わせください。
- アイデンティティプロバイダにサインインして JWT を取得したら、安全な場所にあるファイルに保存します。そのファイルの絶対パスを環境変数
WANDB_IDENTITY_TOKEN_FILEに設定します。 - W&B SDK または CLI を使用して W&B プロジェクトにアクセスします。SDK または CLI は JWT を自動的に検出し、検証したうえで W&B アクセストークンと交換します。W&B アクセストークンを使用すると、run、メトリクス、アーティファクトのログなど、AI ワークフローに必要な API にアクセスできます。デフォルトでは、アクセストークンは
~/.config/wandb/credentials.jsonに保存されます。このパスは、環境変数WANDB_CREDENTIALS_FILEを指定して変更できます。
JWT は有効期間の短い認証情報であり、APIキーやパスワードなど有効期間の長い認証情報の欠点を補います。JWT の有効期限は、アイデンティティプロバイダの設定によって異なります。JWT は有効期限が切れる前に更新し、環境変数
WANDB_IDENTITY_TOKEN_FILE で参照されるファイルに保存してください。W&B アクセストークンにもデフォルトの有効期間があり、期限が切れると SDK または CLI は JWT を使用してトークンの更新を試みます。その時点でユーザーの JWT も期限切れのまま更新されていない場合、認証は失敗します。可能であれば、JWT の取得と有効期限切れ後の更新の仕組みを、W&B SDK または CLI を使用する AI ワークロードに組み込んでください。JWT の検証
有効なトークンにのみアクセスを許可するため、JWT に対して次の検証が行われます。これらの検証は、SDK または CLI が JWT を W&B アクセストークンと交換し、project にアクセスする際に実行されます。- W&B は、W&B 組織レベルの JWKS を使用して JWT の署名を検証します。これは最初の防御線です。この検証が失敗した場合は、JWKS または JWT の署名方法に問題があります。
-
JWT の
issクレームは、組織レベルで設定された発行者 URL と一致している必要があります。 -
JWT の
subクレームは、W&B 組織で設定されているユーザーのメールアドレスと一致している必要があります。 -
JWT の
audクレームは、AI ワークフローでアクセスする project が属する W&B 組織の名前と一致している必要があります。 専用クラウド または セルフマネージド インスタンスの場合:- オーディエンスの検証をスキップするには、環境変数
FEDERATED_AUTH_AUDIENCESをwandbに設定します。 - 組織によっては、オーディエンスに固有の要件がある場合があります。
audの値をカスタマイズするには、環境変数FEDERATED_AUTH_AUDIENCESに、オーディエンスの値をカンマ区切りで列挙した文字列を設定します。
- オーディエンスの検証をスキップするには、環境変数
-
W&B は JWT の
expクレームを確認し、トークンが有効か、有効期限切れで更新が必要かを判断します。
外部サービスアカウント
W&B では以前から、有効期間の長い APIキーを持つ組み込みのサービスアカウントをサポートしてきました。SDK と CLI 向けのアイデンティティ フェデレーションを使用すると、認証に JWT を使用する外部サービスアカウントも利用できます。これらの JWT は、組織で設定された発行者が発行したものである必要があります。チーム管理者は、組み込みのサービスアカウントと同様に、チームのスコープ内で外部サービスアカウントを設定できます。 外部サービスアカウントを設定するには、チーム管理者が次の手順を実行します。- チームの Service Accounts タブにアクセスします。
- New service account をクリックします。
- サービスアカウントの名前を入力します。
- Authentication Method として Federated Identity を選択し、Subject を入力します。詳しくは、アイデンティティプロバイダの Subject 値を決定するを参照してください。
- Create をクリックします。
sub クレームは、チーム管理者がチームレベルの Service Accounts タブで設定した Subject と一致している必要があります。W&B は、JWT の検証の一環としてこのクレームを確認します。aud クレームの要件は、人間のユーザーの JWT と同様です。
外部サービスアカウントの JWT を使用して W&B にアクセスする場合は、ワークフローを自動化すると多くの場合効率的です。オートメーションによって初回の JWT が生成され、必要に応じて更新されます。外部サービスアカウントでログした run を人間のユーザーに関連付けるには、組み込みのサービスアカウントと同様に、AI ワークフローで環境変数 WANDB_USERNAME または WANDB_USER_EMAIL を設定します。
W&B では、データの機密度が異なる AI ワークロード全体で、組み込みのサービスアカウントと外部サービスアカウントを組み合わせて使用することを推奨しています。両者を組み合わせることで、柔軟性とシンプルさを両立できます。
アイデンティティプロバイダの Subject の値を確認する
Subject に入力する値は、IdP がサービスアカウント向けに発行する JWT のsub (subject) クレームと完全に一致している必要があります。W&B は、どのアイデンティティプロバイダに対しても同じ方法で比較します。照合は完全一致で、大文字と小文字、および空白が区別されます。そのため、末尾にスペースが 1 つあったり、大文字と小文字が違っていたりするだけで認証に失敗します。
Subject の値は IdP に完全に依存するため、W&B アプリは空でない Subject であれば、値を検証せずに受け入れます。サービスアカウントの作成時点では、W&B は誤った値を検出できません。値が誤っている場合は、後でサービスアカウントが JWT を提示した時点で認証に失敗します。
正しい値を確認する最も確実な方法は、実際のトークンから読み取ることです。サービスアカウント向けに発行されたサンプルの JWT を取得し、そのペイロード (2 つのドットに挟まれた中央のセグメント) をローカルで base64url デコードして、sub の値をそのまま Subject フィールドにコピーしてください。JWT は認証情報であるため、サードパーティのオンラインデコーダーには貼り付けないでください。
値はプロバイダーによって異なります。以下は一般的な例ですが、必ず実際のトークンで確認してください。