> ## 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.

# サンドボックスポリシーを設定する

> クラスター上のサンドボックスが要求できる範囲を制限する制約と、サンドボックスに継承されるデフォルトを設定します。

このページでは、クラスター上のサンドボックスを管理するポリシーの作成方法について説明します。ポリシーでは、コンピュート、イメージ、ネットワークアクセス、セキュリティポスチャーに制約を設け、すべてのサンドボックスが継承するデフォルトを設定します。このページは、ランナーを管理する管理者を対象としています。

ポリシーはランナーに含まれるため、ポリシーの作成はランナーを更新して行います。ポリシー専用のリソースやエンドポイントはありません。サンドボックスがポリシーに基づいてどのように解決されるかについては、[ポリシーの概要](/ja/products/sandboxes/profiles/profiles)を参照してください。

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

組織内で **Sandbox Admin** ロールが付与されている必要があります。このロールがない状態でポリシーの読み取りまたは書き込みを行うと、`PermissionDenied` が返されます。

CLI のサンプルを使用するには、[CoreWeave Intelligent CLI](https://github.com/coreweave/cwic) をインストールして認証してください。REST のサンプルを使用するには、CoreWeave API トークンが必要です。サンプルでは、このトークンを `$TOKEN`、ランナーを `prod-us-east-1` と表記しています。

すべてのランナーには必ず 1 つのポリシーが設定されており、ポリシーは必須です。ベースも制約も持たないポリシーも有効であり、その場合は制限が一切ないポスチャーを宣言したことになります。これにより、オペレーターは意図せずポスチャーを継承することなく、常にポスチャーを明示的に指定することになります。

<h2 id="read-the-current-policy">
  現在のポリシーを読み取る
</h2>

空のドキュメントから作成するのではなく、ランナーに現在設定されている内容を出発点にします。

<Tabs>
  <Tab title="CLI">
    ```bash theme={"system"}
    cwic sandbox runner policy get prod-us-east-1
    ```

    詳細を表示するには `describe` を使用します。ランナーにポリシーがない場合は、未設定の状態であることが明示的に表示されます。

    ```bash theme={"system"}
    cwic sandbox runner policy describe prod-us-east-1
    ```

    `-o json` を指定すると、一度も設定されたことのないランナーでは `{}` ではなく `null` が返されます。そのため、オートメーションで「未設定」と「設定済みで制限なし」を区別できます。
  </Tab>

  <Tab title="curl">
    ```bash title="ランナーとそのポリシーを読み取る" theme={"system"}
    curl https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1 \
      -H "Authorization: Bearer $TOKEN"
    ```
  </Tab>
</Tabs>

<h2 id="update-a-policy">
  ポリシーを更新する
</h2>

ポリシーはランナーのフィールドであるため、更新マスク `policy` を指定してランナーを更新することで設定します。

**ポリシーを更新すると、常にドキュメント全体が置き換えられます。** 更新マスクのパスとして実装されているのは `policy` のみであるため、1 つの制約グループだけを変更して残りをそのまま維持することはできません。現在のポリシーを読み取り、必要な箇所を変更してから、ドキュメント全体を送信してください。

<Tabs>
  <Tab title="CLI">
    ランナーの現在のドキュメントが入力された状態の `$EDITOR` でポリシーを編集します。

    ```bash theme={"system"}
    cwic sandbox runner policy edit prod-us-east-1
    ```

    ファイルから、または `-` を指定して標準入力からドキュメントを適用します。

    ```bash theme={"system"}
    cwic sandbox runner policy edit prod-us-east-1 -f policy.yaml
    ```

    `-f` を指定した場合、`cwic` は送信時点でランナーの現在のリビジョンを読み取ります。そのため、それより前に読み取った内容をもとに編集したファイルで、他の管理者の変更を上書きしてしまう可能性があります。ファイルの基になったリビジョンを固定するには、ランナーを 1 回読み取り、その結果からポリシーとその `etag` を取得します。

    ```bash theme={"system"}
    cwic sandbox runner get prod-us-east-1 -o json > runner.json
    jq '.[0].policy' runner.json > policy.json
    ```

    `policy.json` を編集し、同じ読み取りで得た `etag` を指定して送信します。

    ```bash theme={"system"}
    cwic sandbox runner policy edit prod-us-east-1 -f policy.json \
      --etag "$(jq -r '.[0].etag' runner.json)"
    ```

    `etag` は必ずドキュメントを取得したときと同じ読み取りから取得し、後の読み取りから取得しないでください。`policy get` はポリシーを `etag` なしでエクスポートします。また、エクスポート後に `policy describe` を実行すると、より新しいトークンが返される場合があります。このトークンはチェックを通過してしまうため、その間に行われた変更がファイルの内容で上書きされます。curl タブと[ポリシーを置き換える](/ja/products/sandboxes/operations/managed-runners#example-replace-the-policy)でも、同様に 1 つのレスポンスから両方を取得しています。

    エディターモードでは、エディターに読み込むために取得した `etag` がそのまま送信されるため、フラグは不要です。

    現在のドキュメントではなくひな形から作成するには、テンプレートを出力します。

    ```bash theme={"system"}
    cwic sandbox runner policy edit prod-us-east-1 --print-template
    ```

    送信前にドキュメントを検証します。

    ```bash theme={"system"}
    cwic sandbox runner policy validate -f policy.yaml
    ```
  </Tab>

  <Tab title="curl">
    `[ETAG]` は、この編集の基になった読み取りで得た `etag` の値に置き換えてください。古い値を指定すると `FAILED_PRECONDITION` で失敗し、何も変更されません。詳しくは、[ポリシーを置き換える](/ja/products/sandboxes/operations/managed-runners#example-replace-the-policy)を参照してください。

    ```bash title="ランナーにポリシーを設定する" theme={"system"}
    curl -X PATCH "https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1?updateMask=policy" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "policy": {
          "displayName": "Shared agent pool",
          "constraints": {
            "resources": { "maxCpu": "8", "maxMemory": "32Gi", "requireLimits": true },
            "lifecycle": { "defaultLifetimeSeconds": 3600 }
          }
        },
        "etag": "[ETAG]"
      }'
    ```
  </Tab>
</Tabs>

ポリシーの書き込みには、常に次の 3 つのルールが適用されます。

* **有効期間の上限は、ポリシーではなくプラットフォームによって決まります。** ポリシーで指定できるのは `constraints.lifecycle.defaultLifetimeSeconds` のみで、この値は作成リクエストで有効期間が省略された場合に使用されます。プラットフォームは作成時に、上限 (現在は 30 日) を超える有効期間を拒否します。以前のバージョンのポリシーには `maxLifetimeSeconds` による上限がありましたが、現在の `cwic` はこれを含むドキュメントを拒否します。
* **一度設定したポリシーはクリアできません。** 削除操作はなく、ポリシーを null に設定する更新は API によって拒否されます。ポスチャーを緩和するには、より制限の緩いドキュメントに置き換えてください。
* **ポリシードキュメントのサイズ上限は、エンコード後で 256 KiB です。**

<Warning>
  ポリシーの書き込みは「読み取り・変更・書き込み」の流れで行われ、編集の基になったランナーの読み取りで得た `etag` と照合されます。その読み取り以降に他の管理者がポリシーを更新していた場合、API は `FAILED_PRECONDITION` で書き込みを拒否し、何も変更されません。その場合はランナーを再度読み取り、返されたドキュメントに変更を適用し直してから、新しい `etag` を指定して再送信してください。新しい `etag` だけを取得して、元のドキュメントをそのまま再送信するとチェックは通過します。ただし、書き込みではドキュメント全体が置き換えられるため、他の管理者による編集は失われます。
</Warning>

有効期間の例や、Serverless と CKS の相違点については、[長時間実行されるサンドボックスを実行する](/ja/products/sandboxes/long-running-sandboxes)を参照してください。

ポリシーの変更は、更新後に作成されたサンドボックスに適用されます。実行中のサンドボックスには、起動時に解決されたポリシーが引き続き適用されます。また、ゲートウェイにキャッシュされたコピーは反映が少し遅れることがあるため、書き込みの直後に行われた配置では、以前のポリシーに基づいて解決される場合があります。

<Note>
  ポリシー関連のコマンドは v1 API に対して読み書きを行いますが、その他の `cwic sandbox runner` および `cwic sandbox profile` コマンドは引き続き v1beta2 を使用します。どちらも同じ `--api-url` 経由でアクセスします。
</Note>

<h2 id="set-a-default-policy-for-new-runners">
  新しいランナーのデフォルトポリシーを設定する
</h2>

CoreWeave のホスト型サービスでは、新しいランナー向けのデフォルトポリシーを CoreWeave が設定しています。それ以外のデプロイメントでは、独自のデフォルトを定義できます。ゲートウェイは、ランナーが接続したとき、または v1 配置がポリシーのないランナーを初めて選択したときに、そのポリシーを書き込みます。すでにポリシーがあるランナーでは、既存のポリシーがそのまま維持されます。

デフォルトはゲートウェイのインフラストラクチャー設定 `gateway.infraConfig.default_runner_policy` で定義します。変更を反映するにはゲートウェイの再起動が必要です。組み込みのデフォルトはありません。この設定が存在しないか null の場合は何も書き込まれず、サンドボックスは引き続き `CWSANDBOX_POOL_POLICY_NOT_CONFIGURED` で拒否されます。

この機能を利用する前に、次の 2 つの動作を把握しておいてください。

* **デフォルトはリンクではなく、スナップショットです。** ランナーに書き込まれた時点で、そのポリシーは通常のランナーのポリシーとして扱われます。その後 `default_runner_policy` を変更しても、すでにポリシーが設定されているランナーには反映されません。それらのランナーは `UpdateManagedRunner` で更新してください。
* **デフォルトが無効な場合、サンドボックスを作成できなくなります。** ゲートウェイは起動時に設定されたポリシーを検証します。検証に失敗してもゲートウェイ自体は起動しますが、サンドボックスの作成は `CWSANDBOX_SERVERLESS_MISCONFIGURED` で失敗します。

<h2 id="constrain-compute">
  コンピュートを制限する
</h2>

`resources` は、コンテナーが要求できるリソースの上限を定めるとともに、サンドボックスで何も要求が指定されていない場合に使用されるデフォルト値を提供します。

```json theme={"system"}
{
  "constraints": {
    "resources": {
      "minCpu": "500m",
      "maxCpu": "8",
      "defaultCpu": "2",
      "minMemory": "1Gi",
      "maxMemory": "32Gi",
      "defaultMemory": "4Gi",
      "maxGpuCount": "2",
      "requireLimits": true
    }
  }
}
```

`requireLimits` を `true` に設定すると、CPU とメモリの両方の制限を宣言していないサンドボックスは拒否されます。`cpuCeiling` と `memoryCeiling` を使用すると、サンドボックスごとに解決後の合計値の上限を設定できます。これは、ベースレイヤー側でも独自のコンテナーが追加される場合に重要になります。

`maxGpuCount` は、1 つのサンドボックスが要求できる GPU 数の上限を設定します。省略すると上限は適用されません。`0` に設定するとすべての GPU リクエストが拒否されるため、GPU を使用しないプールとして構成できます。上限を超えるリクエストは `CWSANDBOX_RESOURCE_CEILING_EXCEEDED` エラーで失敗します。

<h2 id="constrain-images">
  イメージを制限する
</h2>

`image` は、サンドボックスのイメージの取得元を制限します。グループが空の場合は、すべてのイメージが許可されます。`[GITHUB-ORG]` は、GitHub Container Registry の組織名またはユーザー名に置き換えてください。

```json theme={"system"}
{
  "constraints": {
    "image": {
      "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"],
      "allowedImages": ["ghcr.io/[GITHUB-ORG]/agent-base:2024.11"]
    }
  }
}
```

<h2 id="constrain-network-access">
  ネットワークアクセスを制約する
</h2>

ネットワーク制約は、許容範囲として機能します。サンドボックスが外向き通信を宣言した場合、ポリシーはその宣言を広げることなく、受け入れるか拒否するかを判定します。サンドボックスが外向き通信を宣言しない場合、ポリシーは外向き通信のデフォルトを適用します。ただし、サンドボックスが `deny_egress` を設定している場合は除きます。

2 つの設定は、それぞれ別の役割を担います。

* `allowedEgress` は外向き通信の許可リストで、サンドボックスの作成時にチェックされます。空でない場合、サンドボックスが宣言するすべてのルールがこの範囲内に収まる必要があります。範囲外のルールは、範囲を狭めて受け入れられるのではなく、拒否されます。空の場合は、任意のルールを宣言できます。
* `defaultEgress` は、リクエストがない場合の扱いを定義します。サンドボックスが独自の外向き通信を宣言しておらず、かつ `deny_egress` を設定していない場合にのみ適用されます。何らかの宣言があれば、その宣言に完全に置き換えられます。

1 つのルールでは、1 つの送信先を指定します。`cidr`(オプションで `except` による除外範囲を指定可能)、他のサンドボックスとの関係を表す `tenant`、ラベルで選択したワークロードを表す `selector`、HTTPS ホスト名を表す `httpsHostname`、または `any` を使用します。オプションの `ports` を指定すると、ルールをさらに絞り込めます。ホスト名ルールで許可されるのは TCP 443 のみで、ホスト名ルールをサポートするランナーが必要です。ホスト名ルールは `allowedEgress` とサンドボックスのリクエストで指定するもので、`defaultEgress` には指定できません。

```json theme={"system"}
{
  "constraints": {
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "0.0.0.0/0", "except": ["10.0.0.0/8", "169.254.169.254/32"] } },
        { "tenant": "TENANT_SCOPE_SAME_ORG" }
      ],
      "defaultEgress": [
        { "tenant": "TENANT_SCOPE_SAME_ORG" }
      ]
    }
  }
}
```

この例では、プライベートアドレス空間とインスタンスメタデータのアドレスを除外したうえでパブリックインターネットへのアクセスを許可し、さらに同じ組織内の他のサンドボックスへのアクセスも許可しています。何も宣言していないサンドボックスには、同じ組織内へのアクセスのみが許可されます。

テナントスコープには `TENANT_SCOPE_SAME_USER` と `TENANT_SCOPE_SAME_ORG` があります。3 つ目の値である `TENANT_SCOPE_SANDBOX_NETWORK` はまだサポートされておらず、これを使用する外向き通信ルールは拒否されます。

イングレスでは、可視性が `CUSTOM` のポートに対して `allowedIngress` と `defaultIngress` を使用します。許可リストが空でない場合、宣言されたすべてのイングレスルールはその範囲内に収まる必要があります。サンドボックスがイングレスルールを宣言せずに `CUSTOM` ポートを公開した場合は、`deny_ingress` が設定されていない限り、`defaultIngress` が適用されます。明示的なイングレスルールを指定すると、このデフォルトは置き換えられます。イングレスルールで指定できるのは `cidr`、`tenant`、`any` のみで、名前ベースのソースは指定できません。

ホスト名ベースの HTTPS ルールを拒否するには、`denyHttpsHostnameRules` を設定します。この設定では、DNS クエリや、CIDR ルールで許可された HTTPS はブロックされません。外向きの UDP/TCP ポート 53 をブロックするには、`dnsEgress` を `DNS_EGRESS_MODE_DENY` に設定します。省略した場合は、プラットフォームのリゾルバーへの DNS アクセスが許可されます。プラットフォームの DNS とストレージへのアクセスは、送信先ルールとは別に許可されます。包含ルールと DNS の動作については、[ネットワーク制約](/ja/products/sandboxes/reference/profile#networkconstraints)を参照してください。

<h2 id="constrain-security-posture">
  セキュリティポスチャーを制限する
</h2>

`security` は、ゲスト内の権限と、サンドボックスの実行時に適用される分離を制御します。

```json theme={"system"}
{
  "constraints": {
    "security": {
      "allowPrivileged": false,
      "allowedCapabilities": ["NET_BIND_SERVICE"],
      "allowedSeccompProfiles": ["RuntimeDefault"],
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu"
    }
  }
}
```

`allowedRuntimeClasses` はフェイルクローズで動作します。リストが空または未指定の場合、ランタイムクラスの固定は一切許可されません。そのため、サンドボックスがクラスを選択できるのは、リストにクラスを明示的に記載した場合のみです。サンドボックスが何も固定しない場合に適用されるクラスを指定するには、`defaultCpuRuntimeClass` と `defaultGpuRuntimeClass` を設定します。

<h2 id="constrain-instances-lifetime-metadata-and-volumes">
  インスタンス、有効期間、メタデータ、ボリュームを制限する
</h2>

残りのグループは、いずれも設定項目が少数です。

| グループ | フィールド | 効果 |
| - | - | - |
| `instance` | `allowedInstanceTypes` | サンドボックスを配置できるノードのインスタンスタイプを制限します。 |
| `lifecycle` | `defaultLifetimeSeconds` | サンドボックスが有効期間を指定しなかった場合に適用される有効期間です。すべてのサンドボックスには、プラットフォームの上限 (現在は 30 日) が適用されます。`maxLifetimeSeconds` はポリシードキュメントから削除されたため、指定すると拒否されます。 |
| `metadata` | `deniedAnnotationPrefixes`, `maxAnnotationCount` | 接頭辞に一致するアノテーションキーを拒否し、サンドボックスが設定できるアノテーション数に上限を設けます。`0` は無制限を意味します。 |
| `volumes` | `allowedMedia`, `maxSize` | 使用できるストレージメディアを制限し、ボリュームごとのサイズに上限を設けます。RAM ベースのボリュームを禁止するには、`STORAGE_MEDIUM_MEMORY` を除外します。 |

```json theme={"system"}
{
  "constraints": {
    "lifecycle": { "defaultLifetimeSeconds": 3600 },
    "volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "100Gi" }
  }
}
```

<h2 id="the-base-layer">
  ベースレイヤー
</h2>

制約は、サンドボックスが要求できる範囲を制限します。一方、`base` レイヤーは、サンドボックスが要求しなくても一律に付与される設定を提供します。具体的には、スケジューラー、ノードセレクター、トレランス、サービスアカウント、イメージプルシークレットといったデフォルト値や付加設定です。その形式はランナーのランタイムによって異なり、Kubernetes ランナーでは Pod spec の一部 (フラグメント) となります。

<h2 id="next-steps">
  次のステップ
</h2>

* [ポリシーの概要](/ja/products/sandboxes/profiles/profiles): サンドボックスに適用されるポリシーの解決方法と、プロフィールからの変更点について説明します。
* [ランナーのデプロイと管理](/ja/products/sandboxes/operations/managed-runners): ランナーのライフサイクルと、その他のランナー設定について説明します。
* [コントロールプレーン API の概要](/ja/products/sandboxes/reference/control-plane-api): 認証、フィールドマスク、エンドポイントの仕様について説明します。