長期間有効なAPIキーの代わりに、アイデンティティ フェデレーションを使用して、組織の認証情報でW&B SDKおよびCLIにサインインできます。W&B組織管理者が組織に対してSSOを設定している場合、W&B App UIにはすでにそれらの認証情報でサインインしています。アイデンティティ フェデレーションはW&B SDK向けのSSOに似ていますが、JSON Web Tokens (JWT) を直接使用する点が異なります。アイデンティティ フェデレーションは、APIキーの代替として使用できます。 このページは、W&B組織のJWT issuerを設定する組織管理者向けです。また、JWTを使用してW&Bに認証するユーザーやサービスアカウント向けでもあります。 RFC 7523は、SDKでのアイデンティティ フェデレーションの基盤となる仕様です。Documentation Index
Fetch the complete documentation index at: https://wb-21fd5541-docs-2661.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
アイデンティティ フェデレーションは、Multi-tenant Cloud、専用クラウド、セルフマネージドでプレビューとして利用できます。Enterprise ライセンスが必要です。詳細や
サポートが必要な場合は、担当のAISEまたはサポートにお問い合わせください。
このドキュメントでは、“アイデンティティプロバイダ”と”JWT issuer”という用語を同じ意味で使用しています。どちらも、この機能の文脈では同じものを指します。
JWT issuer を設定する
- 組織のダッシュボードで Settings タブにアクセスします。
- Authentication オプションで、Set up JWT Issuer をクリックします。
- テキストボックスに JWT issuer の URL を入力し、Create をクリックします。
${ISSUER_URL}/.well-known/openid-configuration のパスにある OIDC discovery document を自動的に参照します。discovery document から、W&B は該当する URL にある JSON Web Key Set (JWKS) を特定します。W&B は JWKS を使用して JWT をリアルタイムで検証し、該当するアイデンティティプロバイダによって発行されたことを確認します。
この手順を完了すると、W&B 組織は JWT issuer とフェデレーションされます。すると、組織内の Users は、その provider が発行した JWT を使用して W&B に認証できるようになります。
JWT を使用して W&B にアクセスする
- 組織で利用可能な方法のいずれかを使用して、アイデンティティプロバイダにサインインする必要があります。一部のプロバイダには API または SDK を使用して自動的にアクセスできますが、関連する UI からしかアクセスできないものもあります。詳細については、W&B 組織管理者または JWT issuer の所有者にお問い合わせください。
- アイデンティティプロバイダにサインインして JWT を取得したら、安全な場所にあるファイルに保存します。絶対ファイルパスを環境変数
WANDB_IDENTITY_TOKEN_FILEに設定してください。 - W&B SDK または CLI を使用して、W&B のプロジェクトにアクセスします。SDK または CLI は JWT を自動的に検出し、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 検証
- W&B は、W&B 組織レベルの JWKS を使用して JWT 署名を検証します。これは最初の防御策であり、ここで失敗する場合は、JWKS または JWT の署名方法に問題があることを示します。
-
JWT の
issクレームは、組織レベルで設定された issuer URL と一致している必要があります。 -
JWT の
subクレームは、W&B 組織で設定されたユーザーのメールアドレスと一致している必要があります。 -
JWT の
audクレームは、AI ワークフローの一環としてアクセスするプロジェクトが属する W&B 組織の名と一致している必要があります。 専用クラウド または セルフマネージド インスタンスでは:- audience の検証をスキップするには、環境変数
FEDERATED_AUTH_AUDIENCESをwandbに設定できます。 - 一部の組織では、audience に対して特定の要件があります。
audの値をカスタマイズするには、環境変数FEDERATED_AUTH_AUDIENCESに、audience 値をカンマ区切りで並べた文字列を設定します。
- audience の検証をスキップするには、環境変数
-
W&B は JWT の
expクレームをチェックして、トークンが有効か、期限切れで更新が必要かどうかを判断します。
外部サービスアカウント
- チームの Service Accounts タブにアクセスします。
- New service account をクリックします。
- サービスアカウントの名前を入力し、Authentication Method として Federated Identity を選択し、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 ワークロード全体で、組み込みサービスアカウントと外部サービスアカウントを組み合わせて使用することを推奨します。この組み合わせにより、柔軟性とシンプルさのバランスを取ることができます。