> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# サンドボックスに AI Object Storage へのアクセスを許可する

> サンドボックスが組み込みの OIDC トークンを一時的な AI Object Storage の認証情報と交換できるようにします

すべての CoreWeave サンドボックスには、組み込みの OIDC トークンを持たせることができます。このトークンは、[Workload Identity Federation (WIF)](/products/storage/object-storage/auth-access/workload-identity-federation/about) を通じて一時的な CoreWeave AI Object Storage 認証情報と交換されます。サンドボックスのコントロールプレーンがトークンを発行してコンテナーにマウントし、AWS SDK が読み取る環境変数を設定するため、有効期間の長いアクセスキーを注入しなくても、サンドボックスからバケットの読み書きができます。

このページは、組織ごとに一度だけ信頼関係を設定する管理者と、その後、個々のサンドボックスでオブジェクトストレージへのアクセスをリクエストする研究者を対象としています。設定が完了すると、自動的に期限切れになる認証情報を使用して、サンドボックスからバケットに対して `aws s3` コマンドや Boto3 コードを実行できます。

<h2 id="how-it-works">
  仕組み
</h2>

サンドボックスゲートウェイは、各サンドボックスに固定の CoreWeave 発行者 `https://oidc.cwsandbox.com` から JSON Web Token (JWT) を発行します。AI Object Storage は、組織内のワークロードフェデレーション設定に対してそのトークンを検証し、トークンの `iss` および `sub` クレームからロールアイデンティティを導出し、アクセスポリシーによってスコープされた一時的な認証情報を返します。

3 つの設定を揃える必要があります。

| 設定 | 場所 | 内容 |
| - | - | - |
| OIDC ワークロードフェデレーション設定 | Cloud console の **Organization** > **IAM** | `https://oidc.cwsandbox.com` からのトークンを AI Object Storage が信頼するよう指示します。**設定 ID** を生成します。 |
| 組織のアクセスポリシー | AI Object Storage | 導出されたサンドボックスロールに、トークンの交換およびバケットに対する操作を許可します。 |
| サンドボックス WIF 設定 | サンドボックスコントロールプレーン | サンドボックスコントロールプレーンに設定 ID を指定し、サンドボックスがリクエストできるバケットおよび権限レベルを制限します。 |

導出されるロールアイデンティティの形式は `role/https://oidc.cwsandbox.com:user:[USER-ID]` です。ここで `[USER-ID]` は、API アクセストークンでサンドボックスを開始した呼び出し元の CoreWeave ユーザー ID です。サブジェクトはユーザーごとに異なるため、アクセスポリシーでは各ユーザーのロールを列挙するか、発行者全体を末尾のワイルドカードで一致させます。[サンドボックスロールへの権限付与](#step-2-grant-permissions-to-the-sandbox-role) を参照してください。

サンドボックス内では、独自の認証情報取得プロセスは必要ありません。AWS SDK のコンテナー認証情報プロバイダーは、マウントされたトークンを読み取り、CoreWeave の認証情報エンドポイントを呼び出して、有効期限が切れる前に認証情報を更新します。

<h2 id="before-you-begin">
  始める前に
</h2>

管理者向けの手順では、以下が必要です。

* AI Object Storage が有効化された CoreWeave 組織と、少なくとも 1 つのバケット。作成方法については、[バケットを作成する](/products/storage/object-storage/buckets/create-bucket) を参照してください。
* 組織の管理者権限: **IAM Admin** および **Object Storage Admin** のロール、または同等のレガシーアクセス。
* アイデンティティとアクセス管理 (IAM) における `SANDBOX_ADMIN` action。これにより、サンドボックスの WIF 設定を設定できます。[Access Policies](https://console.coreweave.com/organization/iam/access-policies) ページの Cloud Console で付与します。
* CoreWeave 組織 ID。[Settings](https://console.coreweave.com/account/settings) ページの Cloud Console に表示されます。
* CoreWeave API アクセストークン。[Tokens](https://console.coreweave.com/tokens) ページで生成し、**Token Secret** の値をコピーします。詳細については、[API アクセストークンを管理する](/security/authn-authz/manage-api-access-tokens) を参照してください。

このページの `curl` の例で読み取れるようにトークンをエクスポートします。`[API-ACCESS-TOKEN]` を CoreWeave API アクセストークンに置き換えてください。

```bash theme={"system"}
export TOKEN="[API-ACCESS-TOKEN]"
```

研究者向けのステップを進めるには、利用可能なサンドボックス環境が必要です。まだ用意していない場合は、まず [はじめに](/ja/products/sandboxes/get-started) の手順に従ってください。

<h2 id="step-1-create-an-oidc-workload-federation-config">
  ステップ 1: OIDC ワークロードフェデレーション設定の作成
</h2>

サンドボックス発行者を組織に登録して、AI Object Storage がサンドボックストークンを受け入れるようにします。

1. Cloud console で [Workload Federation](https://console.coreweave.com/organization/iam/workload-federation/oidc) ページに移動します。

2. **Create OIDC configuration** をクリックします。

3. 次の値を指定します。

   * **Name**: この設定を識別する名前 (例: `coreweave-sandboxes`) 。
   * **Issuer URL**: `https://oidc.cwsandbox.com`
   * **Client ID (Audience)**: `https://oidc.cwsandbox.com`
   * **Description** (オプション): この設定の説明。

4. **Create** をクリックします。

<Warning>
  発行者ホストにハイフンはありません。サンドボックストークンは発行者クレーム `https://oidc.cwsandbox.com` を保持しており、トークン検証ではこの値を正確に比較するため、`https://oidc.cw-sandbox.com` に対して作成された設定は一致しません。
</Warning>

設定が作成されると、Workload Federation ページに **設定 ID** が表示されます。この値をコピーしてください。[ステップ 3](#step-3-register-the-wif-configuration-with-the-sandbox-control-plane) で必要になります。

この時点で AI Object Storage はサンドボックストークンを検証できますが、結果のロールにはまだ権限がありません。

<h2 id="step-2-grant-permissions-to-the-sandbox-role">
  ステップ 2: サンドボックスロールに権限を付与する
</h2>

組織のアクセスポリシーは、サンドボックスが受け取った認証情報で何ができるかを決定します。2 つのグラントが必要です。トークン交換 action は Global である一方、S3 action はバケットにスコープされるため、別々のステートメントにする必要があります。

以下のポリシーはトークン交換をグラントします。`cwobject:CreateAccessKeyOIDC` action はすべてのリソースで動作するため、そのステートメントでは `"resources": ["*"]` を使用します。`[USER-ID]` を、サンドボックスを開始する API アクセストークンを持つ CoreWeave ユーザーの ID に置き換えてください。

```json highlight={9-14} theme={"system"}
{
  "policy": {
    "version": "v1alpha1",
    "name": "allow-sandbox-oidc-key-creation",
    "statements": [
      {
        "name": "allow-create-access-key-from-sandbox-oidc",
        "effect": "Allow",
        "actions": [
          "cwobject:CreateAccessKeyOIDC"
        ],
        "resources": ["*"],
        "principals": [
          "role/https://oidc.cwsandbox.com:user:[USER-ID]"
        ]
      }
    ]
  }
}
```

組織内のすべてのユーザーをカバーするために、各サブジェクトをリストアップせずに、プリンシパルは末尾にワイルドカードを受け入れます: `role/https://oidc.cwsandbox.com:*`。発行者部分は完全に一致する必要があるため、この付与はサンドボックストークンにのみ適用され、他のアイデンティティプロバイダーには適用されません。

次に、認証情報にバケットに対してアクションを実行する権限を付与します。サンドボックスが使用するバケットに合わせて `[BUCKET-NAME]` を置き換えてください:

```json highlight={16-19} theme={"system"}
{
  "policy": {
    "version": "v1alpha1",
    "name": "sandbox-read-write-bucket",
    "statements": [
      {
        "name": "allow-sandbox-rw-bucket",
        "effect": "Allow",
        "actions": [
          "s3:Get*",
          "s3:List*",
          "s3:Put*",
          "s3:DeleteObject"
        ],
        "resources": [
          "[BUCKET-NAME]",
          "[BUCKET-NAME]/*"
        ],
        "principals": [
          "role/https://oidc.cwsandbox.com:*"
        ]
      }
    ]
  }
}
```

2 番目のポリシーがない場合、トークンの交換は成功しますが、すべてのバケットの操作は拒否されます。完全なスキーマについては、[組織のアクセスポリシー](/products/storage/object-storage/auth-access/organization-policies/about) を参照してください。

両方のステートメントが設定されていれば、サンドボックスロールはトークンを認証情報と交換し、リストしたバケットに対して操作を実行できます。

組織のアクセスポリシーは、ほとんどのデプロイメントで十分です。クロス組織アクセスが必要な場合や、トークンのクレームを使用してアクセスを制限したい場合にのみ、[バケットのアクセスポリシー](/products/storage/object-storage/auth-access/bucket-access/bucket-policies) を追加してください。バケットポリシーでは、同じプリンシパルが完全な ARN 形式 `arn:aws:iam::[ORG-ID]:role/https://oidc.cwsandbox.com:*` を取り、クレームは `oidc:[ORG-ID]:[CLAIM]` という名前の条件キーとして参照されます。サンドボックストークンが持つクレームについては、[トークンのクレーム](#token-claims) を参照してください。

<h2 id="step-3-register-the-wif-configuration-with-the-sandbox-control-plane">
  ステップ 3: WIF 設定をサンドボックス コントロールプレーンに登録する
</h2>

サンドボックス コントロールプレーンに対し、どのワークロードフェデレーション設定でトークンを発行するかを指定し、組織内のサンドボックスがリクエストできる上限を設定します。組織ごとに 1 つの設定があり、リクエストはべき等な upsert です。

`[WIF-CONFIG-ID]` を [ステップ 1](#step-1-create-an-oidc-workload-federation-config) の 設定 ID に、 `[BUCKET-NAME]` を許可する各バケットに置き換えます：

```bash title="Set the sandbox WIF configuration" theme={"system"}
curl -X PUT "https://api.cwsandbox.com/v1beta2/object-storage/wif-config" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "wifConfigId": "[WIF-CONFIG-ID]",
    "enabled": true,
    "allowedBuckets": ["[BUCKET-NAME]"],
    "maxPermission": "OBJECT_STORAGE_PERMISSION_READ_WRITE"
  }'
```

各フィールドの動作は次のとおりです。

| フィールド | 必須 | 説明 |
| - | - | - |
| `wifConfigId` | はい | Cloud Console のワークロードフェデレーション設定の設定 ID。 |
| `maxPermission` | はい | サンドボックスがリクエストできる最高アクセスレベル：`OBJECT_STORAGE_PERMISSION_READ` または `OBJECT_STORAGE_PERMISSION_READ_WRITE`。 |
| `enabled` | いいえ | デフォルトは `true` です。設定を削除せずにオブジェクトストレージへのアクセスを無効にするには、`false` に設定します。 |
| `allowedBuckets` | いいえ | サンドボックスがリクエストできるバケット名。空のリストではすべてのバケットが許可されます。 |

組織は認証済みの呼び出し元から取得されるため、リクエストボディに組織フィールドはなく、呼び出し元は自身の組織の設定のみを管理できます。

設定が保存されたことを確認します。

```bash title="Get the sandbox WIF configuration" theme={"system"}
curl "https://api.cwsandbox.com/v1beta2/object-storage/wif-config" \
  -H "Authorization: Bearer $TOKEN"
```

新しいオブジェクトストレージの認証情報を発行しないようにするには、設定を削除します：

```bash title="Delete the sandbox WIF configuration" theme={"system"}
curl -X DELETE "https://api.cwsandbox.com/v1beta2/object-storage/wif-config" \
  -H "Authorization: Bearer $TOKEN"
```

設定を削除すると、オブジェクトストレージへのアクセスを求める新しいサンドボックスのリクエストは拒否されます。すでに実行中のサンドボックスは、トークンの有効期限が切れるまで動作し続けます。

各フィールドのリファレンスについては、コントロールプレーン API リファレンスの[オブジェクトストレージの WIF 設定を設定する](/ja/products/sandboxes/reference/control-plane-api)を参照してください。

<h2 id="step-4-request-object-storage-access-when-you-start-a-sandbox">
  ステップ 4: サンドボックスの起動時にオブジェクトストレージへのアクセスをリクエストする
</h2>

ステップ 1 から 3 は、管理者が組織に対して一度だけ行う設定です。残りのステップは、オブジェクトストレージを必要とするサンドボックスごとに研究者が行います。

オブジェクトストレージへのアクセスは、サンドボックスごとに明示的に有効にする必要があります。起動リクエストに `objectStorageAccess` を追加し、サンドボックスが必要とするバケットと権限レベルを指定します。`[CONTAINER-IMAGE]` を、サンドボックスで実行するイメージに置き換えてください。

```bash title="Start a sandbox with object storage access" highlight={7-12} theme={"system"}
curl -X POST "https://api.cwsandbox.com/v1beta2/sandboxes" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "containerImage": "[CONTAINER-IMAGE]",
    "command": "sleep",
    "args": ["3600"],
    "objectStorageAccess": {
      "buckets": ["[BUCKET-NAME]"],
      "permission": "OBJECT_STORAGE_PERMISSION_READ_WRITE"
    }
  }'
```

どちらのフィールドも、[ステップ 3](#step-3-register-the-wif-configuration-with-the-sandbox-control-plane) の組織設定によって制限されます。`buckets` リストは `allowedBuckets` のサブセットである必要があり、`permission` は `maxPermission` を超えることはできません。組織で許可されている範囲を超えるリクエストは拒否されます。また、組織に有効な WIF 設定がない場合のリクエストも拒否されます。

上限より狭い範囲をリクエストすることには意義があります。トレーニングデータを読み取るだけのサンドボックスでは、組織の上限が読み取りと書き込みであっても、`OBJECT_STORAGE_PERMISSION_READ` をリクエストするべきです。

<h2 id="step-5-use-the-credentials-inside-the-sandbox">
  ステップ 5: サンドボックス内で認証情報を使用する
</h2>

サンドボックスが `objectStorageAccess` を指定して起動すると、コントロールプレーンはその OIDC トークンをマウントし、AWS SDK が[コンテナー認証情報](https://docs.aws.amazon.com/sdkref/latest/guide/feature-container-credentials.html)に使用する環境変数を設定します。

| 変数 | 値 |
| - | - |
| `AWS_CONTAINER_CREDENTIALS_FULL_URI` | `https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]` |
| `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` | `/var/run/secrets/sandbox/storage-token/osa-token` |
| `AWS_ENDPOINT_URL_S3` | AI Object Storage のエンドポイント (例: `https://cwobject.com`) |

トークン自体は、`/var/run/secrets/sandbox/storage-token/osa-token` にある読み取り専用ファイルです。これを読み取る必要はありません。また、サンドボックスの外にコピーしたり、別のワークロードに渡したりしないでください。

クライアントライブラリが認証情報の交換を行います。バケットのリージョンを設定し、S3互換のクライアントを使用してください。`[AVAILABILITY-ZONE]` を、バケットがある Availability Zone (例: `US-EAST-04A`) に置き換えてください。

```bash title="List objects from inside a sandbox" theme={"system"}
export AWS_REGION="[AVAILABILITY-ZONE]"

aws configure set s3.addressing_style virtual

aws s3 ls s3://[BUCKET-NAME]/
```

AI Object Storage には仮想ホスト形式のアドレス指定が必要です。パス形式のリクエストは `PathStyleRequestNotAllowed` で失敗します。

Boto3 は同じ環境変数を読み込むため、認証情報を明示的に指定する必要はありません。次の例では、サンドボックス環境からエンドポイントとリージョンを読み取り、バケット内のオブジェクトを一覧表示します。

```python title="list_objects.py" theme={"system"}
import os

import boto3
from botocore.client import Config

boto_config = Config(
    region_name=os.environ['AWS_REGION'],
    s3={'addressing_style': 'virtual'}
)

s3 = boto3.client(
    's3',
    endpoint_url=os.environ['AWS_ENDPOINT_URL_S3'],
    config=boto_config
)

response = s3.list_objects_v2(Bucket=os.environ['BUCKET_NAME'])

for item in response.get('Contents', []):
    print(item['Key'], item['Size'])
```

`BUCKET_NAME` にアクセス権を付与したバケットを設定し、サンドボックス内で実行します。

```bash theme={"system"}
export BUCKET_NAME="[BUCKET-NAME]"

python list_objects.py
```

成功時の出力には、各オブジェクトキーとそのサイズ (バイト単位) が表示されます：

```text title="Example output" theme={"system"}
datasets/train/shard-00000.tar 268435456
datasets/train/shard-00001.tar 268435456
datasets/val/shard-00000.tar 67108864
```

<Note>
  認証情報の交換には、ループバック以外のホストに対するコンテナー認証情報の SDK サポートが必要です。`awscli` 2.33.2 以降、または `boto3` 1.42.5 以降を使用してください。古いバージョンでは `Unsupported host 'api.coreweave.com'` エラーで失敗します。これらのバージョンをサンドボックスのコンテナーイメージに組み込んでください。
</Note>

<h2 id="token-lifetimes">
  トークンの有効期間
</h2>

サンドボックスの OIDC トークンと、それを使って取得する一時的な認証情報は、それぞれ異なるタイミングで期限切れになります。

* **サンドボックスの OIDC トークン**: デフォルトは 1 時間で、最大 12 時間です。サンドボックスの起動時にコントロールプレーンが発行します。
* **AI Object Storage の一時的な認証情報**: トークンから必要に応じて発行されます。交換時の応答には `Expiration` タイムスタンプが含まれ、AWS SDK はその時刻より前に認証情報を更新するため、コード側での対応は不要です。

サンドボックスが OIDC トークンの有効期限を超えて稼働すると、トークンを交換できなくなり、オブジェクトストレージの操作が権限エラーで失敗します。長時間稼働するサンドボックスでは、起動リクエストで `maxLifetimeSeconds` を設定し、トークンがサンドボックスの有効期間全体をカバーするようにしてください。

<h2 id="token-claims">
  トークンのクレーム
</h2>

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

| クレーム | 説明 |
| - | - |
| `iss` | 常に `https://oidc.cwsandbox.com` です。 |
| `sub` | `user:[USER-ID]`。サンドボックスを起動した CoreWeave ユーザーです。`iss` と組み合わせてロールアイデンティティを導出します。 |
| `aud` | ワークロードフェデレーション設定で指定したオーディエンスです。 |
| `org_id` | サンドボックスを所有する CoreWeave 組織です。 |
| `wif_config_id` | トークンの発行に使用されたワークロードフェデレーション設定の ID です。 |
| `buckets` | `objectStorageAccess` でリクエストされたバケットです。 |
| `permission` | `objectStorageAccess` でリクエストされた権限レベルです。 |
| `exp` | Unix タイムスタンプ形式の有効期限です。 |

<h2 id="troubleshooting">
  トラブルシューティング
</h2>

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

<h3 id="the-start-request-is-rejected">
  起動リクエストが拒否される
</h3>

`objectStorageAccess` を指定した起動リクエストが失敗する場合は、次の点を確認してください。

* 組織に、`enabled` が `true` に設定された設定があること。この設定は、[ステップ 3](#step-3-register-the-wif-configuration-with-the-sandbox-control-plane) の Get リクエストで取得できます。
* リクエスト内のすべてのバケットが `allowedBuckets` に含まれていること、または `allowedBuckets` が空であること。
* リクエストした `permission` が `maxPermission` を超えていないこと。

<h3 id="credential-exchange-returns-permission-denied">
  認証情報の交換でアクセス拒否が返される
</h3>

最初の 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 トークンが期限切れになっていないこと。新しいトークンを発行するには、サンドボックスを再起動してください。

<h3 id="credential-exchange-succeeds-but-s3-operations-return-accessdenied">
  認証情報の交換は成功したが、S3 操作で AccessDenied が返される
</h3>

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

<h3 id="the-credential-request-times-out">
  認証情報リクエストがタイムアウトする
</h3>

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

<h3 id="the-workload-creates-a-large-number-of-access-keys">
  ワークロードが大量のアクセスキーを作成する
</h3>

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

<h2 id="related-pages">
  関連ページ
</h2>

* [Workload Identity Federation for AI Object Storage](/products/storage/object-storage/auth-access/workload-identity-federation/about): CoreWeave 全体での WIF の仕組みについて。
* [Use Workload Identity Federation with OIDC](/products/storage/object-storage/auth-access/workload-identity-federation/use-oidc-tokens): サンドボックス以外のアイデンティティプロバイダー向けの一般的な OIDC フェデレーションガイド。
* [組織のアクセスポリシー](/products/storage/object-storage/auth-access/organization-policies/about): [ステップ 2](#step-2-grant-permissions-to-the-sandbox-role) で使用されるポリシースキーマ。
* [Sandboxes architecture](/ja/products/sandboxes/architecture): サンドボックスリクエストパスにおけるゲートウェイとランナーの位置について。