Skip to main content
すべての CoreWeave サンドボックスには、組み込みの OIDC トークンを持たせることができます。このトークンは、Workload Identity Federation (WIF) を通じて一時的な CoreWeave AI Object Storage 認証情報と交換されます。サンドボックスのコントロールプレーンがトークンを発行してコンテナーにマウントし、AWS SDK が読み取る環境変数を設定するため、有効期間の長いアクセスキーを注入しなくても、サンドボックスからバケットの読み書きができます。 このページは、組織ごとに一度だけ信頼関係を設定する管理者と、その後、個々のサンドボックスでオブジェクトストレージへのアクセスをリクエストする研究者を対象としています。設定が完了すると、自動的に期限切れになる認証情報を使用して、サンドボックスからバケットに対して aws s3 コマンドや Boto3 コードを実行できます。

仕組み

サンドボックスゲートウェイは、各サンドボックスに固定の CoreWeave 発行者 https://oidc.cwsandbox.com から JSON Web Token (JWT) を発行します。AI Object Storage は、組織内のワークロードフェデレーション設定に対してそのトークンを検証し、トークンの iss および sub クレームからロールアイデンティティを導出し、アクセスポリシーによってスコープされた一時的な認証情報を返します。 3 つの設定を揃える必要があります。 導出されるロールアイデンティティの形式は role/https://oidc.cwsandbox.com:user:[USER-ID] です。ここで [USER-ID] は、API アクセストークンでサンドボックスを開始した呼び出し元の CoreWeave ユーザー ID です。サブジェクトはユーザーごとに異なるため、アクセスポリシーでは各ユーザーのロールを列挙するか、発行者全体を末尾のワイルドカードで一致させます。サンドボックスロールへの権限付与 を参照してください。 サンドボックス内では、独自の認証情報取得プロセスは必要ありません。AWS SDK のコンテナー認証情報プロバイダーは、マウントされたトークンを読み取り、CoreWeave の認証情報エンドポイントを呼び出して、有効期限が切れる前に認証情報を更新します。

始める前に

管理者向けの手順では、以下が必要です。
  • AI Object Storage が有効化された CoreWeave 組織と、少なくとも 1 つのバケット。作成方法については、バケットを作成する を参照してください。
  • 組織の管理者権限: IAM Admin および Object Storage Admin のロール、または同等のレガシーアクセス。
  • アイデンティティとアクセス管理 (IAM) における SANDBOX_ADMIN action。これにより、サンドボックスの WIF 設定を設定できます。Access Policies ページの Cloud Console で付与します。
  • CoreWeave 組織 ID。Settings ページの Cloud Console に表示されます。
  • CoreWeave API アクセストークン。Tokens ページで生成し、Token Secret の値をコピーします。詳細については、API アクセストークンを管理する を参照してください。
このページの curl の例で読み取れるようにトークンをエクスポートします。[API-ACCESS-TOKEN] を CoreWeave API アクセストークンに置き換えてください。
研究者向けのステップを進めるには、利用可能なサンドボックス環境が必要です。まだ用意していない場合は、まず はじめに の手順に従ってください。

ステップ 1: OIDC ワークロードフェデレーション設定の作成

サンドボックス発行者を組織に登録して、AI Object Storage がサンドボックストークンを受け入れるようにします。
  1. Cloud console で Workload Federation ページに移動します。
  2. Create OIDC configuration をクリックします。
  3. 次の値を指定します。
    • Name: この設定を識別する名前 (例: coreweave-sandboxes) 。
    • Issuer URL: https://oidc.cwsandbox.com
    • Client ID (Audience): https://oidc.cwsandbox.com
    • Description (オプション): この設定の説明。
  4. Create をクリックします。
発行者ホストにハイフンはありません。サンドボックストークンは発行者クレーム https://oidc.cwsandbox.com を保持しており、トークン検証ではこの値を正確に比較するため、https://oidc.cw-sandbox.com に対して作成された設定は一致しません。
設定が作成されると、Workload Federation ページに 設定 ID が表示されます。この値をコピーしてください。ステップ 3 で必要になります。 この時点で AI Object Storage はサンドボックストークンを検証できますが、結果のロールにはまだ権限がありません。

ステップ 2: サンドボックスロールに権限を付与する

組織のアクセスポリシーは、サンドボックスが受け取った認証情報で何ができるかを決定します。2 つのグラントが必要です。トークン交換 action は Global である一方、S3 action はバケットにスコープされるため、別々のステートメントにする必要があります。 以下のポリシーはトークン交換をグラントします。cwobject:CreateAccessKeyOIDC action はすべてのリソースで動作するため、そのステートメントでは "resources": ["*"] を使用します。[USER-ID] を、サンドボックスを開始する API アクセストークンを持つ CoreWeave ユーザーの ID に置き換えてください。
組織内のすべてのユーザーをカバーするために、各サブジェクトをリストアップせずに、プリンシパルは末尾にワイルドカードを受け入れます: role/https://oidc.cwsandbox.com:*。発行者部分は完全に一致する必要があるため、この付与はサンドボックストークンにのみ適用され、他のアイデンティティプロバイダーには適用されません。 次に、認証情報にバケットに対してアクションを実行する権限を付与します。サンドボックスが使用するバケットに合わせて [BUCKET-NAME] を置き換えてください:
2 番目のポリシーがない場合、トークンの交換は成功しますが、すべてのバケットの操作は拒否されます。完全なスキーマについては、組織のアクセスポリシー を参照してください。 両方のステートメントが設定されていれば、サンドボックスロールはトークンを認証情報と交換し、リストしたバケットに対して操作を実行できます。 組織のアクセスポリシーは、ほとんどのデプロイメントで十分です。クロス組織アクセスが必要な場合や、トークンのクレームを使用してアクセスを制限したい場合にのみ、バケットのアクセスポリシー を追加してください。バケットポリシーでは、同じプリンシパルが完全な ARN 形式 arn:aws:iam::[ORG-ID]:role/https://oidc.cwsandbox.com:* を取り、クレームは oidc:[ORG-ID]:[CLAIM] という名前の条件キーとして参照されます。サンドボックストークンが持つクレームについては、トークンのクレーム を参照してください。

ステップ 3: WIF 設定をサンドボックス コントロールプレーンに登録する

サンドボックス コントロールプレーンに対し、どのワークロードフェデレーション設定でトークンを発行するかを指定し、組織内のサンドボックスがリクエストできる上限を設定します。組織ごとに 1 つの設定があり、リクエストはべき等な upsert です。 [WIF-CONFIG-ID] を ステップ 1 の 設定 ID に、 [BUCKET-NAME] を許可する各バケットに置き換えます:
Set the sandbox WIF configuration
各フィールドの動作は次のとおりです。 組織は認証済みの呼び出し元から取得されるため、リクエストボディに組織フィールドはなく、呼び出し元は自身の組織の設定のみを管理できます。 設定が保存されたことを確認します。
Get the sandbox WIF configuration
新しいオブジェクトストレージの認証情報を発行しないようにするには、設定を削除します:
Delete the sandbox WIF configuration
設定を削除すると、オブジェクトストレージへのアクセスを求める新しいサンドボックスのリクエストは拒否されます。すでに実行中のサンドボックスは、トークンの有効期限が切れるまで動作し続けます。 各フィールドのリファレンスについては、コントロールプレーン API リファレンスのオブジェクトストレージの WIF 設定を設定するを参照してください。

ステップ 4: サンドボックスの起動時にオブジェクトストレージへのアクセスをリクエストする

ステップ 1 から 3 は、管理者が組織に対して一度だけ行う設定です。残りのステップは、オブジェクトストレージを必要とするサンドボックスごとに研究者が行います。 オブジェクトストレージへのアクセスは、サンドボックスごとに明示的に有効にする必要があります。起動リクエストに objectStorageAccess を追加し、サンドボックスが必要とするバケットと権限レベルを指定します。[CONTAINER-IMAGE] を、サンドボックスで実行するイメージに置き換えてください。
Start a sandbox with object storage access
どちらのフィールドも、ステップ 3 の組織設定によって制限されます。buckets リストは allowedBuckets のサブセットである必要があり、permission は maxPermission を超えることはできません。組織で許可されている範囲を超えるリクエストは拒否されます。また、組織に有効な WIF 設定がない場合のリクエストも拒否されます。 上限より狭い範囲をリクエストすることには意義があります。トレーニングデータを読み取るだけのサンドボックスでは、組織の上限が読み取りと書き込みであっても、OBJECT_STORAGE_PERMISSION_READ をリクエストするべきです。

ステップ 5: サンドボックス内で認証情報を使用する

サンドボックスが objectStorageAccess を指定して起動すると、コントロールプレーンはその OIDC トークンをマウントし、AWS SDK がコンテナー認証情報に使用する環境変数を設定します。 トークン自体は、/var/run/secrets/sandbox/storage-token/osa-token にある読み取り専用ファイルです。これを読み取る必要はありません。また、サンドボックスの外にコピーしたり、別のワークロードに渡したりしないでください。 クライアントライブラリが認証情報の交換を行います。バケットのリージョンを設定し、S3互換のクライアントを使用してください。[AVAILABILITY-ZONE] を、バケットがある Availability Zone (例: US-EAST-04A) に置き換えてください。
List objects from inside a sandbox
AI Object Storage には仮想ホスト形式のアドレス指定が必要です。パス形式のリクエストは PathStyleRequestNotAllowed で失敗します。 Boto3 は同じ環境変数を読み込むため、認証情報を明示的に指定する必要はありません。次の例では、サンドボックス環境からエンドポイントとリージョンを読み取り、バケット内のオブジェクトを一覧表示します。
list_objects.py
BUCKET_NAME にアクセス権を付与したバケットを設定し、サンドボックス内で実行します。
成功時の出力には、各オブジェクトキーとそのサイズ (バイト単位) が表示されます:
Example output
認証情報の交換には、ループバック以外のホストに対するコンテナー認証情報の SDK サポートが必要です。awscli 2.33.2 以降、または boto3 1.42.5 以降を使用してください。古いバージョンでは Unsupported host 'api.coreweave.com' エラーで失敗します。これらのバージョンをサンドボックスのコンテナーイメージに組み込んでください。

トークンの有効期間

サンドボックスの OIDC トークンと、それを使って取得する一時的な認証情報は、それぞれ異なるタイミングで期限切れになります。
  • サンドボックスの OIDC トークン: デフォルトは 1 時間で、最大 12 時間です。サンドボックスの起動時にコントロールプレーンが発行します。
  • AI Object Storage の一時的な認証情報: トークンから必要に応じて発行されます。交換時の応答には Expiration タイムスタンプが含まれ、AWS SDK はその時刻より前に認証情報を更新するため、コード側での対応は不要です。
サンドボックスが OIDC トークンの有効期限を超えて稼働すると、トークンを交換できなくなり、オブジェクトストレージの操作が権限エラーで失敗します。長時間稼働するサンドボックスでは、起動リクエストで maxLifetimeSeconds を設定し、トークンがサンドボックスの有効期間全体をカバーするようにしてください。

トークンのクレーム

サンドボックスのオブジェクトストレージトークンには、以下のクレームが含まれます。バケットポリシーの条件では、oidc:[ORG-ID]:[CLAIM] として参照します。

トラブルシューティング

以下のセクションでは、サンドボックスのオブジェクトストレージへのアクセスを設定または使用する際によく発生する障害と、それぞれの確認事項について説明します。

起動リクエストが拒否される

objectStorageAccess を指定した起動リクエストが失敗する場合は、次の点を確認してください。
  • 組織に、enabled が true に設定された設定があること。この設定は、ステップ 3 の Get リクエストで取得できます。
  • リクエスト内のすべてのバケットが allowedBuckets に含まれていること、または allowedBuckets が空であること。
  • リクエストした permission が maxPermission を超えていないこと。

認証情報の交換でアクセス拒否が返される

最初の S3 操作が権限エラーで失敗する場合、交換自体が拒否されています。次の点を確認してください。
  • 組織のアクセスポリシーが、独立したステートメントでサンドボックスのロールに "resources": ["*"] に対する cwobject:CreateAccessKeyOIDC を許可していること。
  • ポリシーのプリンシパルが、サブジェクトの user: 接頭辞も含め、導出されたロールと完全に一致していること。プリンシパルは role/https://oidc.cwsandbox.com:[USER-ID] ではなく、role/https://oidc.cwsandbox.com:user:[USER-ID] です。
  • Cloud Console のワークロードフェデレーション設定が有効で、発行者 URL がハイフンを含まない https://oidc.cwsandbox.com であること。
  • サンドボックスの OIDC トークンが期限切れになっていないこと。新しいトークンを発行するには、サンドボックスを再起動してください。

認証情報の交換は成功したが、S3 操作で AccessDenied が返される

交換は成功しましたが、結果の認証情報にバケットの権限がありません。組織のアクセスポリシーが、短い形式のバケットリソース ([BUCKET-NAME] と [BUCKET-NAME]/*) に対して必要な s3: action をサンドボックスのロールに付与していることを確認してください。バケットのアクセスポリシーも適用されている場合は、Deny ステートメントがないか確認してください。これらは Allow を上書きするものです。

認証情報リクエストがタイムアウトする

許可リストのみの下り(egress)通信を使用するポリシーが適用されたサンドボックスは、https://api.coreweave.com に到達できる必要があります。この経路がない場合、認証情報の取得がタイムアウトし、最初の S3 操作が失敗します。ポリシーの下り通信の許可リストで、このホストへのアクセスを許可してください。詳細はサンドボックスポリシーを設定するを参照してください。

ワークロードが大量のアクセスキーを作成する

交換のたびに、有効期間の短いアクセスキーが作成されます。作業項目ごとに新しいクライアントを構築するのではなく、SDK の認証情報プロバイダーに、プロセスが実行されている間、認証情報をキャッシュして更新させてください。リクエストごとにキーを発行すると、利点がないまま大量のキーが生成されます。
最終更新日 2026年10月15日