サービスアカウントを使用してワークフローを自動化する

サービスアカウントは、チーム内の project 間、またはチーム間で一般的なタスクを自動的に実行できる、人間ではないユーザーやマシンユーザーを表します。サービスアカウントは、CI/CD パイプライン、自動化されたトレーニング ジョブ、その他のマシン間ワークフローに最適です。 このページでは、サービスアカウントで使用できるスコープを説明し、作成と管理の手順を紹介するとともに、本番環境のオートメーションで安全に使用するためのベストプラクティスをまとめます。自動化システム用の認証情報をプロビジョニングする組織管理者とチーム管理者を対象としています。

​

主なメリット

サービスアカウントの主な利点:

• ライセンスを消費しない: サービスアカウントはユーザーシートやライセンスを消費しません。
• 専用のAPIキー: 自動化されたワークフロー向けの安全な認証情報を使用できます。
• ユーザー属性の付与: 必要に応じて、自動化された run を実際のユーザーに関連付けることができます。
• エンタープライズ対応: 大規模な本番オートメーション向けに設計されています。
• 委譲された操作: サービスアカウントは、作成したユーザーまたは組織に代わって操作を実行します。

​

概要

サービスアカウントを使用すると、個人のユーザー認証情報やハードコードされた認証情報に頼ることなく、W&B のワークフローを安全に自動化できます。サービスアカウントは 2 つのスコープで作成できます。

• 組織スコープ: 組織管理者が作成し、すべてのチームにアクセスできます。
• チームスコープ: チーム管理者が作成し、アクセスは特定のチームに限定されます。

サービスアカウントの APIキーを使用すると、呼び出し元はサービスアカウントのスコープ内にある project の読み取りや書き込みを行えます。これにより、W&B Models での実験管理や W&B Weave でのトレースのログといった自動化ワークフローを一元管理できます。 サービスアカウントは、次のような用途に役立ちます。

• CI/CD パイプライン: GitHub Actions、GitLab CI、Jenkins からモデル トレーニング run を自動的にログします。
• スケジュールされたジョブ: 夜間のモデル再トレーニング、定期的な評価 run、データ検証のワークフローなど。
• 本番モニタリング: 本番システムから推論メトリクスやモデル性能をログします。
• Jupyter ノートブック: JupyterHub や Google Colab 環境での共有ノートブック。
• Kubernetes ジョブ: Kubernetes クラスターで実行される自動化ワークフロー。
• Airflow/Prefect/Dagster: ML パイプラインのオーケストレーションツール。

​

組織スコープのサービスアカウント

オートメーションが複数のチームの project にわたって読み書きする必要がある場合、組織スコープのサービスアカウントを使用します。組織にスコープされたサービスアカウントは、チームに関係なく、組織内のすべての project で読み書きする権限を持ちます。ただし、制限付きプロジェクト を除きます。組織スコープのサービスアカウントが制限付きプロジェクトにアクセスするには、その project の管理者が明示的にサービスアカウントを project に追加する必要があります。

​

組織スコープのサービスアカウントを作成する

組織スコープのサービスアカウントとAPIキーを新規作成するには、次の手順に従います。

1. W&B にログインします。
2. ユーザープロフィールアイコンをクリックし、Service Accounts に移動します。
   • 専用クラウド または セルフマネージド: Organization Dashboard をクリックし、Service Accounts をクリックします。
   • Multi-tenant Cloud: Service Accounts をクリックします。
3. Create service account をクリックします。
4. 名前を入力し、デフォルトのチームを選択します。
5. Create をクリックします。
6. 作成したサービスアカウントを検索し、action () メニューから Create API key をクリックします。
7. APIキーの名前を入力し、Create をクリックします。
8. APIキーをコピーし、安全な場所に保管します。
9. Done をクリックします。

​

チームスコープのサービスアカウント

オートメーションを単一のチームの project に限定したい場合、最小権限の原則に従ってチームスコープのサービスアカウントを使用します。チームスコープのサービスアカウントは、そのチーム内のすべての project で読み書きできますが、そのチーム内の制限付きプロジェクト を除きます。チームスコープのサービスアカウントが制限付きプロジェクトにアクセスするには、その project の管理者が明示的にサービスアカウントを project に追加する必要があります。

​

チームスコープのサービスアカウントを作成する

新しいチームスコープのサービスアカウントと APIキーを作成するには、次の手順に従います。

1. チームの設定で Service Accounts をクリックします。
2. New Team Service Account をクリックします。
3. サービスアカウントの名を入力します。
4. Authentication Method を Generate API key (デフォルト) に設定します。Federated Identity を選択した場合、サービスアカウントは APIキーを所有できません。
5. Create をクリックします。
6. 作成したサービスアカウントを検索し、その action () メニューをクリックして、Create API key をクリックします。
7. APIキーの名を入力し、Create をクリックします。
8. APIキーをコピーし、安全に保管します。
9. Done をクリックします。

​

サービスアカウントの追加のAPIキーを作成する

サービスアカウントが所有するAPIキーを作成するには、次の手順を実行します。

1. チーム設定または組織設定で、Service Accounts タブに移動します。
2. 一覧から対象のサービスアカウントを検索します。
3. action () メニューをクリックし、Create API key をクリックします。
4. APIキーの名を入力し、Create をクリックします。
5. 表示されたAPIキーをすぐにコピーし、安全な場所に保管してください。
6. Done をクリックします。

1つのサービスアカウントに複数のAPIキーを作成して、さまざまな環境やワークフローをサポートできます。

​

サービスアカウントのAPIキーを削除する

組織サービスアカウントまたはチームサービスアカウントが所有するAPIキーを削除するには、次の手順に従います。

1. 組織設定に移動し、API Keys をクリックします。
2. 対象のAPIキーを検索します。一覧には、組織サービスアカウントとチームサービスアカウントが所有するすべてのAPIキーが表示されます。キー名または ID で検索やフィルターを行えるほか、任意の列で並べ替えることもできます。
3. 削除ボタンをクリックします。

チームスコープのサービスアカウントを使用するモデル トレーニング環境または生成 AI アプリ環境でチームを設定しない場合、モデルの run または Weave トレースは、サービスアカウントの親チーム内の指定された project にログされます。この場合、参照先のユーザーがサービスアカウントの親チームに所属していない限り、WANDB_USERNAME または WANDB_USER_EMAIL 変数によるユーザー属性の付与は_機能しません_。

​

外部サービスアカウント

W&B ネイティブの APIキーを管理する代わりに、ご自身のアイデンティティプロバイダを通じて認証情報を発行したい場合は、外部サービスアカウントを使用します。組み込みのサービスアカウントに加えて、W&B は W&B SDK および CLI を使用して、JSON Web Token (JWT) を発行するアイデンティティプロバイダとの アイデンティティ フェデレーション を用いたチームスコープの外部サービスアカウントもサポートします。

​

ベストプラクティス

サービスアカウントを作成したら、組織内でのサービスアカウントの安全かつ効率的な使用を確保するため、以下の推奨事項に従ってください。

• シークレットマネージャーの使用: サービスアカウントのAPIキーを平文の設定ファイルではなく、安全なシークレット管理システム (例: AWS Secrets Manager、HashiCorp Vault、Azure Key Vault) に保存します。
• 最小権限の原則: 組織スコープのアカウントではなく、チームスコープのサービスアカウントを可能な限り作成し、必要な project のみにアクセスを制限します。
• ユースケースごとの一意のサービスアカウント: 異なるオートメーションワークフローごとに個別のサービスアカウントを作成します (例: CI/CD用、定期的な再トレーニング用) 。これにより監査可能性が向上し、きめ細かなアクセス制御が可能になります。
• 定期的な監査: アクティブなサービスアカウントを定期的に確認し、使用しなくなったものを削除します。監査ログを確認してサービスアカウントのアクティビティを監視します。
• APIキーの安全な処理:
  • APIキーをバージョン管理にコミットしない。
  • 環境変数を使用してアプリケーションにキーを渡す。
  • 誤って公開された場合はキーをローテーションする。
• 命名規則: サービスアカウントの目的を示す説明的な名前を使用します。
  • 推奨: ci-model-training、nightly-eval-pipeline、prod-inference-monitor
  • 非推奨: service-account-1、test-sa、temp
• ユーザー属性の付与: 複数のチームメンバーが同じオートメーションワークフローを使用する場合、WANDB_USERNAME または WANDB_USER_EMAIL を設定して、どのユーザーが各 run をトリガーしたかをトラッキングします。
  export WANDB_API_KEY="[SERVICE_ACCOUNT_KEY]"
  export WANDB_USERNAME="john.doe@company.com"
  
• 環境設定: チームスコープのサービスアカウントの場合、必ず WANDB_ENTITY を設定して、run が正しいチームにログされるようにします。
  export WANDB_ENTITY="ml-team"
  export WANDB_PROJECT="production-models"
  
• エラー処理: 認証の失敗に対する適切なエラー処理とアラートを実装し、サービスアカウントの認証情報に関する問題を迅速に特定できるようにします。
• ドキュメント: 以下のドキュメントを維持します。
  • 存在するサービスアカウントとその目的。
  • 各サービスアカウントを使用するシステムまたはワークフロー。
  • 各アカウントを担当するチームの連絡先情報。

​

トラブルシューティング

サービスアカウントが期待どおりに動作しない場合は、以下のよくある問題と解決策を確認してください。

• 「Unauthorized」エラー: APIキーが正しく設定されていること、およびサービスアカウントが対象の project へのアクセス権を持っていることを確認します。
• run が表示されない: WANDB_ENTITY が正しいチーム名に設定されていることを確認します。
• ユーザー属性の付与が機能しない: WANDB_USERNAME で指定したユーザーがチームのメンバーであることを確認します。
• 制限付きプロジェクトへのアクセスが拒否される: 制限付きプロジェクトのアクセスリストにサービスアカウントを明示的に追加します。