> ## 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. # 実行中のサンドボックスのネットワークアクセスを変更する > NetworkConfig を使用して、ワークロードを再起動せずにサンドボックスの外向き通信ルールと宣言済みのイングレスルールを更新します。 CoreWeave Sandboxes の動的ネットワークポリシーを使用すると、ワークロードを再起動することなく、実行中のサンドボックスのネットワークアクセスを変更できます。たとえば、エージェントが依存関係をダウンロードした後、信頼できないコードを実行する前に外向きトラフィックを制限するといった使い方が可能です。 各サンドボックスは 1 つの `NetworkConfig` を参照します。このリソースには、サンドボックスに適用したいネットワークルールが保持されています。アクセスを変更するには、このリソースを更新します。ただし、リクエストできるルールは、引き続き配置先のネットワークポリシーによって制限されます。このポリシーは、サーバーレスのサンドボックスでは CoreWeave が管理し、CoreWeave Kubernetes Service (CKS) のランナーでは管理者が設定します。 ## 始める前に 動的ネットワークポリシーは、選択したランナーでこの機能が利用可能であれば、サーバーレスと CKS のどちらのサンドボックスでもサポートされます。サーバーレスでは CoreWeave が管理するランナーを使用するため、独自の CKS クラスターやランナーを用意する必要はありません。 始める前に、次の要件を満たしていることを確認してください。 * `sandbox_user` 権限を持つ CoreWeave API アクセストークン。[API アクセストークンを管理する](https://docs.coreweave.com/security/authn-authz/manage-api-access-tokens.md)を参照してください。 * 組織が利用している API で `NetworkConfig` のサポートが有効になっていること。[可用性と前提条件](https://docs.coreweave.com/ja/products/sandboxes/reference/network-configs.md#availability-and-prerequisites)を参照してください。 * サンドボックスが使用するランナーでライブネットワーク更新が有効になっていること。サーバーレスランナーでは CoreWeave がこの設定を管理します。CKS のマネージドランナーでは、`spec.overrides.env.ENABLE_LIVE_NETWORK_UPDATE` を string `"true"` に設定します。[ランナーを管理する](https://docs.coreweave.com/ja/products/sandboxes/operations/managed-runners.md)を参照してください。 * このガイドの例で必要となる HTTPS ホスト名のグラントが、配置先のネットワークポリシーでサポートおよび許可されていること。 * ローカルに `curl` と `jq` がインストールされていること。 例では、サーバーレス配置を使用し、`https://api.cwsandbox.com` に対して [Connect](https://docs.coreweave.com/ja/products/sandboxes/reference/protos.md) 経由で JSON リクエストを送信します。Python および TypeScript クライアントでは `NetworkConfig` の操作は提供されていません。 トークンを設定します。`[API-ACCESS-TOKEN]` を CoreWeave API アクセストークンに置き換えてください。 ```bash title="Set the API token" theme={"system"} export TOKEN="[API-ACCESS-TOKEN]" ``` ## ネットワーク設定を作成してバインドする Python パッケージインデックス (PyPI) とそのダウンロードホストへの HTTPS 通信を許可する設定を、呼び出し元の所有として作成します。ID には組織内で一意のものを選択してください。この例では `build-egress` を使用します。 ```bash title="Create a network configuration" theme={"system"} 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 のメモリを割り当てます。 ```bash title="Create a sandbox with the configuration" theme={"system"} 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 接続をテストします。手順については、[実行ガイド](https://docs.coreweave.com/ja/products/sandboxes/client/guides/execution.md)を参照してください。両方の接続が成功することを確認し、更新後に再実行できるようにプローブのコマンドを保存しておきます。接続に失敗した場合は、問題を解決してから先に進んでください。 アクセスを制限する準備ができたら、サンドボックスの外向き通信のグラントをクリアし、UDP および TCP のポート `53` での外向き DNS を拒否します。この更新によって、宣言済みのイングレスが変更されることはありません。 古い desired state による書き込みを拒否するには、現在の設定を読み取り、その `etag` を更新時に渡します。 ```bash title="Restrict outbound access" theme={"system"} 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 に置き換えて、サンドボックスの状態を確認します。 ```bash title="Inspect sandbox network status" theme={"system"} 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 接続が失敗すること、および既存のワークロードが引き続き実行されていることを検証します。プローブの失敗を適用の証拠とみなす前に、送信先が利用できないなど、無関係な原因による失敗でないかを調査してください。ステータスフィールドは最後に成功した更新を記録したものであり、適用状況をリアルタイムに測定したものではありません。 > [!WARNING] > > 更新では、適用が終了する前に目的の設定が保存される場合があります。一時的な障害が発生すると、以前の適用状態がリストアされないまま、一部の変更だけが適用された状態になることがあります。制限が有効であることを前提とする前に、現在の設定を読み取り、その現在の `etag` を使用して意図したルールを再適用し、トラフィックを検証してください。ランナーによって恒久的に拒否された場合、API は以前の目的の設定のリストアを試みます。[適用の動作とライフサイクル](https://docs.coreweave.com/ja/products/sandboxes/reference/network-configs.md#apply-behavior-and-lifecycle)を参照してください。`etag` が一致しない場合は、設定を再度読み取り、同時に行われた変更との整合を取る必要があります。 ## 設定を再利用または削除する サンドボックスが終了すると、呼び出し元が作成した設定は再利用可能になります。クリーンアップが完了するまでの短い間は、`status.sandboxId` に古い ID が残っている場合があります。この設定は、次のように新しいサンドボックスにバインドすることも、削除することもできます： ```bash title="Delete an unused network configuration" theme={"system"} 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://docs.coreweave.com/ja/products/sandboxes/public-endpoints.md)を参照してください。 * HTTPS ホスト名グラントは、従来どおり TCP ポート `443` 上の HTTPS 専用です。ホスト名グラントを稼働中に変更できるのは、`httpsHostname` グラントを 1 つ以上指定して作成したサンドボックスのみです。ホスト名グラントなしで作成したサンドボックスにホスト名グラントを追加するには、サンドボックスを新規作成してください。 * 一部の古いサンドボックスでは、ホスト名グラントを稼働中に変更できません (削除も含みます) 。更新が `CWSANDBOX_INVALID_REQUEST` で拒否された場合は、必要なグラントを指定してサンドボックスを新規作成してください。 * ランナーが HTTPS ホスト名グラントをサポートしている必要があります。ランナーがホスト名グラントを強制できない場合、ホスト名グラントを追加または変更するリクエストは `CWSANDBOX_INVALID_REQUEST` を返します。 リソースフィールド、更新マスク、エラー処理については、[NetworkConfig API リファレンス](https://docs.coreweave.com/ja/products/sandboxes/reference/network-configs.md)を参照してください。