SDK でフェデレーテッドアイデンティティを使用する
less than a minute
W&B SDKを使用して、組織の資格情報を使用したサインインにアイデンティティ連携を利用します。W&Bの組織管理者が組織向けにSSOを設定している場合、すでに組織の資格情報を使用してW&BアプリのUIにサインインしています。この意味で、アイデンティティ連携はW&B SDKのためのSSOに似ていますが、JSON Web Tokens (JWTs) を直接使用しています。APIキーの代わりにアイデンティティ連携を使用できます。
RFC 7523は、SDKを使用したアイデンティティ連携の基盤を形成しています。
Enterprise
プランで Preview
として利用可能です - SaaS Cloud、Dedicated Cloud、およびセルフマネージドインスタンス。ご質問がある場合は、W&Bチームにお問い合わせください。identity provider
と JWT issuer
という用語は交換可能に使われています。この機能のコンテキストでは、両方とも同じものを指します。JWTイシュア設定
最初のステップとして、組織管理者はW&B組織とアクセス可能なJWTイシュアの間で連携を設定しなければなりません。
- 組織ダッシュボードの Settings タブに移動します。
- Authentication オプションで
Set up JWT Issuer
をクリックします。 - テキストボックスにJWTイシュアのURLを追加し、
Create
を押します。
W&Bは、${ISSUER_URL}/.well-known/oidc-configuration
パスでOIDCディスカバリードキュメントを自動的に探し、ディスカバリードキュメント内の関連URLでJSON Web Key Set (JWKS) を見つけようとします。JWKSは、JWTが関連するアイデンティティプロバイダーによって発行されたものであることを確認するために使用されるリアルタイム検証に利用されます。
W&BへのJWTを使用
JWTイシュアがW&B組織のために設定されると、ユーザーはそのアイデンティティプロバイダーによって発行されたJWTを使用して関連するW&B Projectsへのアクセスを開始できます。JWTを使用するメカニズムは次の通りです:
- 組織内で利用可能なメカニズムの1つを使用して、アイデンティティプロバイダーにサインインする必要があります。一部のプロバイダーはAPIやSDKを使用して自動化された方法でアクセスでき、他のプロバイダーは関連するUIを使用してのみアクセス可能です。詳細については、W&B組織管理者やJWTイシュアの所有者にお問い合わせください。
- アイデンティティプロバイダーにサインインした後、JWTをセキュアな場所に保存し、環境変数
WANDB_IDENTITY_TOKEN_FILE
に絶対ファイルパスを設定してください。 - W&B SDKやCLIを使用してW&Bプロジェクトにアクセスします。SDKやCLIは自動的にJWTを検出し、JWTが正常に検証された後にそれをW&Bアクセストークンと交換します。W&Bアクセストークンは、AIワークフローを有効にするためにrun、メトリクス、アーティファクトのログを記録するための関連するAPIにアクセスするために使用されます。アクセストークンはデフォルトで
~/.config/wandb/credentials.json
のパスに保存されます。環境変数WANDB_CREDENTIALS_FILE
を指定することでそのパスを変更することができます。
JWTは、APIキー、パスワードなどの長期間の資格情報の欠点に対処するための短期間の資格情報として意図されています。あなたのアイデンティティプロバイダーで設定されたJWTの有効期限に応じて、JWTを継続的にリフレッシュし、環境変数 WANDB_IDENTITY_TOKEN_FILE
で参照されるファイルに保存されていることを確認する必要があります。
W&Bアクセストークンにもデフォルトの有効期限があり、SDKまたはCLIは、それがあなたのJWTを使用して自動的にリフレッシュしようとします。その時点でユーザーJWTが期限切れになってリフレッシュされていない場合、認証に失敗する可能性があります。可能であれば、W&B SDKやCLIを使用したAIワークロードの一部として、JWTの取得と有効期限後のリフレッシュメカニズムを実装するべきです。
JWT検証
JWTをW&Bアクセストークンと交換し、プロジェクトにアクセスするためのワークフローの一環として、JWTは以下の検証を受けます:
- JWT署名はW&B組織レベルでJWKSを使用して検証されます。これが最初の防御線であり、これが失敗した場合、あなたのJWKSやJWTの署名に問題があることを意味します。
- JWT内の
iss
クレームは、組織レベルで設定されたイシュアURLと等しいものである必要があります。 - JWT内の
sub
クレームは、W&B組織で設定されたユーザーのメールアドレスと等しいものである必要があります。 - JWT内の
aud
クレームは、AIワークフローの一部としてアクセスしているプロジェクトを保有しているW&B組織の名前と同じである必要があります。Dedicated Cloud または セルフマネージド インスタンスの場合、インスタンスレベルの環境変数SKIP_AUDIENCE_VALIDATION
をtrue
に設定してオーディエンスクレームの検証をスキップするか、wandb
をオーディエンスとして使用します。 - JWT内の
exp
クレームは、トークンが有効で期限が切れていないか、リフレッシュが必要であるかを確認するためにチェックされます。
外部サービスアカウント
W&Bは長期間のAPIキーを持つ組み込みのサービスアカウントを長年にわたりサポートしてきました。SDKとCLIのアイデンティティ連携機能を使用すると、外部サービスアカウントを持ち込むことができ、JWTを使用して認証することも可能です。ただし、それらが組織レベルで設定されている同じイシュアによって発行されている限りです。チーム管理者は、組み込みのサービスアカウントのように、チームの範囲内で外部サービスアカウントを設定することができます。
外部サービスアカウントを設定するには:
- チームの Service Accounts タブに移動します。
New service account
を押します。- サービスアカウントの名前を入力し、
Authentication Method
としてFederated Identity
を選択し、Subject
を提供してCreate
を押します。
外部サービスアカウントのJWT内の sub
クレームは、チーム管理者がチームレベルの Service Accounts タブでそのサブジェクトとして設定したものと同じである必要があります。このクレームは、JWT検証 の一環として検証されます。aud
クレームの要件は、人間のユーザーJWTと同様です。
W&Bへの外部サービスアカウントのJWTを使用するとき、通常、初期JWTを生成し、継続的にリフレッシュするワークフローを自動化する方が簡単です。外部サービスアカウントを使用してログに記録されたrunを人間ユーザーに帰属させる場合、組み込みサービスアカウントと同様に、AIワークフローのために環境変数 WANDB_USERNAME
または WANDB_USER_EMAIL
を設定することができます。
[i18n] feedback_title
[i18n] feedback_question
Glad to hear it! If you have further feedback, please let us know.
Sorry to hear that. Please tell us how we can improve.