実行中のサンドボックスのネットワークアクセスを変更する

CoreWeave Sandboxes の動的ネットワークポリシーを使用すると、ワークロードを再起動することなく、実行中のサンドボックスのネットワークアクセスを変更できます。たとえば、エージェントが依存関係をダウンロードした後、信頼できないコードを実行する前に外向きトラフィックを制限するといった使い方が可能です。各サンドボックスは 1 つの NetworkConfig を参照します。このリソースには、サンドボックスに適用したいネットワークルールが保持されています。アクセスを変更するには、このリソースを更新します。ただし、リクエストできるルールは、引き続き配置先のネットワークポリシーによって制限されます。このポリシーは、サーバーレスのサンドボックスでは CoreWeave が管理し、CoreWeave Kubernetes Service (CKS) のランナーでは管理者が設定します。

始める前に

動的ネットワークポリシーは、選択したランナーでこの機能が利用可能であれば、サーバーレスと CKS のどちらのサンドボックスでもサポートされます。サーバーレスでは CoreWeave が管理するランナーを使用するため、独自の CKS クラスターやランナーを用意する必要はありません。始める前に、次の要件を満たしていることを確認してください。

sandbox_user 権限を持つ CoreWeave API アクセストークン。API アクセストークンを管理するを参照してください。
組織が利用している API で NetworkConfig のサポートが有効になっていること。可用性と前提条件を参照してください。
サンドボックスが使用するランナーでライブネットワーク更新が有効になっていること。サーバーレスランナーでは CoreWeave がこの設定を管理します。CKS のマネージドランナーでは、spec.overrides.env.ENABLE_LIVE_NETWORK_UPDATE を string "true" に設定します。ランナーを管理するを参照してください。
このガイドの例で必要となる HTTPS ホスト名のグラントが、配置先のネットワークポリシーでサポートおよび許可されていること。
ローカルに curl と jq がインストールされていること。

例では、サーバーレス配置を使用し、https://api.cwsandbox.com に対して Connect 経由で JSON リクエストを送信します。Python および TypeScript クライアントでは NetworkConfig の操作は提供されていません。トークンを設定します。[API-ACCESS-TOKEN] を CoreWeave API アクセストークンに置き換えてください。

Set the API token

export TOKEN="[API-ACCESS-TOKEN]"

ネットワーク設定を作成してバインドする

Python パッケージインデックス (PyPI) とそのダウンロードホストへの HTTPS 通信を許可する設定を、呼び出し元の所有として作成します。ID には組織内で一意のものを選択してください。この例では build-egress を使用します。

Create a network configuration

curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.NetworkConfigService/CreateNetworkConfig' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{
    "networkConfig": {
      "networkConfigId": "build-egress",
      "spec": {
        "egress": [
          {"httpsHostname": "pypi.org"},
          {"httpsHostname": "files.pythonhosted.org"}
        ]
      }
    }
  }'

レスポンスは、ID、目的の spec、etag、status を含む NetworkConfig です。作成時にはルールの構文が検証されます。設定をサンドボックスにバインドすると、プラットフォームがランナーのポリシーを確認します。この設定を使用するサーバーレスサンドボックスを作成します。この例では、CPU 1 個と 1 GiB のメモリを割り当てます。

Create a sandbox with the configuration

curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.SandboxService/CreateSandbox' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{
    "sandbox": {
      "spec": {
        "containers": [{
          "name": "main",
          "image": "python:3.12-slim",
          "command": "sleep",
          "args": ["3600"],
          "resources": {"cpu": "1", "memory": "1Gi"}
        }],
        "mode": "SANDBOX_MODE_SERVERLESS",
        "networkConfigId": "build-egress",
        "maxLifetimeSeconds": 3600
      }
    }
  }'

返された sandboxId を保存してください。プラットフォームは、サンドボックスが RUNNING になる前に初期ルールを適用します。CKS の場合は、spec.mode を SANDBOX_MODE_CKS に変更し、必要に応じて spec.runnerIds を選択します。 1 つの設定を同時にバインドできるのは、終了状態ではないサンドボックス 1 つだけです。同じ作成リクエストで spec.networkConfigId とインラインの spec.network の両方を送信しないでください。 networkConfigId を省略すると、プラットフォームがサンドボックス用の設定を作成します。インラインの spec.network ルールがあればそれをコピーし、なければポリシーのデフォルトに解決される空の設定を使用します。割り当て済みの ID は GetSandbox.spec.networkConfigId から読み取ってください。

実行中のサンドボックスのルールを更新する

ルールを変更する前に、実行中のサンドボックス内から pypi.org と files.pythonhosted.org への新しい HTTPS 接続をテストします。手順については、実行ガイドを参照してください。両方の接続が成功することを確認し、更新後に再実行できるようにプローブのコマンドを保存しておきます。接続に失敗した場合は、問題を解決してから先に進んでください。アクセスを制限する準備ができたら、サンドボックスの外向き通信のグラントをクリアし、UDP および TCP のポート 53 での外向き DNS を拒否します。この更新によって、宣言済みのイングレスが変更されることはありません。古い desired state による書き込みを拒否するには、現在の設定を読み取り、その etag を更新時に渡します。

Restrict outbound access

config=$(curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.NetworkConfigService/GetNetworkConfig' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{"networkConfigId":"build-egress"}') &&
etag=$(printf '%s' "$config" | jq -er '.etag') &&
jq -n --arg etag "$etag" '{
  networkConfigId: "build-egress",
  networkConfig: {
    etag: $etag,
    spec: {egress: [], denyEgress: true, dnsEgress: "DNS_EGRESS_MODE_DENY"}
  },
  updateMask: "spec.egress,spec.denyEgress,spec.dnsEgress"
}' | curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.NetworkConfigService/UpdateNetworkConfig' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  --data-binary @-

レスポンスとして、更新後の NetworkConfig が返されます。サンドボックスは同じ ID とプロセスの状態を維持したまま実行を続けます。他のポートで許可されたストレージアクセスなど、プラットフォームが必要とするトラフィックは引き続き利用可能な場合があります。denyEgress は完全なネットワーク分離ではありません。リストをクリアする場合は、明示的なマスクを使用してください。denyEgress が未設定または false の状態で外向き通信のリストを空にすると、ポリシーのデフォルトに戻ります。すべてが拒否されるわけではありません。

結果を検証する

[SANDBOX-ID] を作成時に取得した ID に置き換えて、サンドボックスの状態を確認します。

Inspect sandbox network status

curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.SandboxService/GetSandbox' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{"sandboxId":"[SANDBOX-ID]"}'

サンドボックスが RUNNING のままであること、同じ spec.networkConfigId を参照していること、更新後の status.effectiveEgress、status.effectiveIngress、status.effectiveDnsEgress が報告されていることを確認します。JSON のレスポンスでは、空の繰り返しフィールドが省略される場合があります。更新前に成功した接続プローブを再度実行します。以前にグラントされていた両方のホストへの新しい外向き HTTPS 接続が失敗すること、および既存のワークロードが引き続き実行されていることを検証します。プローブの失敗を適用の証拠とみなす前に、送信先が利用できないなど、無関係な原因による失敗でないかを調査してください。ステータスフィールドは最後に成功した更新を記録したものであり、適用状況をリアルタイムに測定したものではありません。

更新では、適用が終了する前に目的の設定が保存される場合があります。一時的な障害が発生すると、以前の適用状態がリストアされないまま、一部の変更だけが適用された状態になることがあります。制限が有効であることを前提とする前に、現在の設定を読み取り、その現在の etag を使用して意図したルールを再適用し、トラフィックを検証してください。ランナーによって恒久的に拒否された場合、API は以前の目的の設定のリストアを試みます。適用の動作とライフサイクルを参照してください。etag が一致しない場合は、設定を再度読み取り、同時に行われた変更との整合を取る必要があります。

設定を再利用または削除する

サンドボックスが終了すると、呼び出し元が作成した設定は再利用可能になります。クリーンアップが完了するまでの短い間は、status.sandboxId に古い ID が残っている場合があります。この設定は、次のように新しいサンドボックスにバインドすることも、削除することもできます：

Delete an unused network configuration

curl --fail-with-body -sS \
  'https://api.cwsandbox.com/coreweave.sandbox.v1.NetworkConfigService/DeleteNetworkConfig' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Connect-Protocol-Version: 1' \
  -d '{"networkConfigId":"build-egress","allowMissing":true}'

終了状態に達していないサンドボックスがこの設定を使用している間は、設定を削除できません。プラットフォームによって作成された設定は、対応するサンドボックスが終了すると自動的に削除されます。ネットワークの設定内容を別のサンドボックスに引き継ぐには、設定の spec を新しい設定、またはインライン作成時の入力にコピーします。GetSandbox.spec をコピーした場合、コピーされるのは設定 ID であり、独立したルールのセットではありません。

サポートされる変更と制限

動的ネットワークポリシーには、次の変更と制限が適用されます。

外向き通信の送信先グラント、既存の CUSTOM サービスで宣言されたイングレスソース、denyEgress、denyIngress、dnsEgress を更新できます。ルールはランナーのポリシーの範囲内に収める必要があります。
サービスのポートと可視性は、従来どおり作成時にのみ設定できます。公開エンドポイントを参照してください。
HTTPS ホスト名グラントは、従来どおり TCP ポート 443 上の HTTPS 専用です。ホスト名グラントを稼働中に変更できるのは、httpsHostname グラントを 1 つ以上指定して作成したサンドボックスのみです。ホスト名グラントなしで作成したサンドボックスにホスト名グラントを追加するには、サンドボックスを新規作成してください。
一部の古いサンドボックスでは、ホスト名グラントを稼働中に変更できません (削除も含みます) 。更新が CWSANDBOX_INVALID_REQUEST で拒否された場合は、必要なグラントを指定してサンドボックスを新規作成してください。
ランナーが HTTPS ホスト名グラントをサポートしている必要があります。ランナーがホスト名グラントを強制できない場合、ホスト名グラントを追加または変更するリクエストは CWSANDBOX_INVALID_REQUEST を返します。

リソースフィールド、更新マスク、エラー処理については、NetworkConfig API リファレンスを参照してください。

サンドボックス

サンドボックスを使用する

サンドボックスの管理

リファレンス

実行中のサンドボックスのネットワークアクセスを変更する

始める前に

ネットワーク設定を作成してバインドする

実行中のサンドボックスのルールを更新する

結果を検証する

設定を再利用または削除する

サポートされる変更と制限

​始める前に

​ネットワーク設定を作成してバインドする

​実行中のサンドボックスのルールを更新する

​結果を検証する

​設定を再利用または削除する

​サポートされる変更と制限

始める前に

ネットワーク設定を作成してバインドする

実行中のサンドボックスのルールを更新する

結果を検証する

設定を再利用または削除する

サポートされる変更と制限