> ## 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. # Modifier l’accès réseau d’une Sandbox en cours d’exécution > Mettez à jour les règles de trafic sortant et les règles d’ingress déclarées d’une Sandbox au moyen d’un NetworkConfig, sans redémarrer la charge de travail. Les politiques réseau dynamiques de CoreWeave Sandbox vous permettent de modifier l’accès réseau d’une Sandbox en cours d’exécution sans redémarrer sa charge de travail. Par exemple, un agent peut télécharger des dépendances, puis restreindre le trafic sortant avant d’exécuter du code non fiable. Chaque Sandbox fait référence à un unique `NetworkConfig`, qui contient les règles réseau souhaitées. Pour modifier l’accès, mettez à jour cette ressource. Les règles que vous pouvez demander restent toutefois limitées par la politique réseau du placement : CoreWeave gère cette politique pour les Sandbox sans serveur, tandis que votre administrateur la configure pour les exécuteurs CoreWeave Kubernetes Service (CKS). ## Avant de commencer Les politiques réseau dynamiques prennent en charge aussi bien les Sandbox sans serveur que les Sandbox CKS, dès lors que la fonctionnalité est disponible sur les exécuteurs sélectionnés. Le mode sans serveur s'appuie sur des exécuteurs managés par CoreWeave : vous n'avez donc besoin ni de votre propre cluster CKS ni de votre propre exécuteur. Avant de commencer, assurez-vous de disposer des éléments suivants : * Un jeton d'accès à l'API CoreWeave doté de l'autorisation `sandbox_user`. Voir [Gérer les jetons d'accès à l'API](https://docs.coreweave.com/security/authn-authz/manage-api-access-tokens.md). * La prise en charge de `NetworkConfig` activée sur l'API qui dessert votre organisation. Voir [Disponibilité et prérequis](https://docs.coreweave.com/fr/products/sandboxes/reference/network-configs.md#availability-and-prerequisites). * Les mises à jour réseau à chaud activées sur l’exécuteur utilisé par votre Sandbox. CoreWeave s'en charge pour les exécuteurs sans serveur. Pour un exécuteur géré CKS, définissez `spec.overrides.env.ENABLE_LIVE_NETWORK_UPDATE` sur la chaîne `"true"`. Voir [Gérer les exécuteurs](https://docs.coreweave.com/fr/products/sandboxes/operations/managed-runners.md). * Des autorisations de nom d'hôte HTTPS prises en charge et permises par la politique réseau du placement, comme l'exigent les exemples de ce guide. * `curl` et `jq` installés localement. Les exemples utilisent un placement sans serveur et des requêtes JSON via [Connect](https://docs.coreweave.com/fr/products/sandboxes/reference/protos.md) à l'adresse `https://api.cwsandbox.com`. Les clients Python et TypeScript n'exposent pas les opérations `NetworkConfig`. Définissez votre jeton. Remplacez `[API-ACCESS-TOKEN]` par votre jeton d'accès à l'API CoreWeave : ```bash title="Set the API token" theme={"system"} export TOKEN="[API-ACCESS-TOKEN]" ``` ## Créer et associer une configuration réseau Créez une configuration appartenant à l’appelant qui autorise le trafic HTTPS vers l’index des paquets Python et son hôte de téléchargement. Choisissez un ID unique au sein de votre organisation. Cet exemple utilise `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"} ] } } }' ``` La réponse est un `NetworkConfig` contenant son ID, la `spec` souhaitée, l’`etag` et le `status`. La syntaxe des règles est validée lors de la création. Lorsque vous associez la configuration à une sandbox, la plateforme vérifie la politique de l’exécuteur. Créez une sandbox sans serveur qui utilise cette configuration. Cet exemple alloue un CPU et 1 Gio de mémoire : ```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 } } }' ``` Enregistrez le `sandboxId` renvoyé. La plateforme applique les règles initiales avant que la sandbox n’atteigne l’état `RUNNING`. Pour CKS, remplacez la valeur de `spec.mode` par `SANDBOX_MODE_CKS` et sélectionnez éventuellement `spec.runnerIds`. Une configuration ne peut être liée qu’à une seule sandbox non terminée à la fois. N'envoyez pas à la fois `spec.networkConfigId` et `spec.network` en ligne dans la même requête de création. Si vous omettez `networkConfigId`, la plateforme crée une configuration pour la sandbox. Elle copie les éventuelles règles `spec.network` en ligne ou, à défaut, utilise une configuration vide qui applique les valeurs par défaut de la politique. Récupérez l’ID attribué dans `GetSandbox.spec.networkConfigId`. ## Mettre à jour les règles de la sandbox en cours d’exécution Avant de modifier les règles, testez de nouvelles connexions HTTPS vers `pypi.org` et `files.pythonhosted.org` depuis la sandbox en cours d’exécution. Pour savoir comment procéder, consultez le [guide d’exécution](https://docs.coreweave.com/fr/products/sandboxes/client/guides/execution.md). Vérifiez que les deux connexions aboutissent, puis enregistrez les commandes de sonde afin de les relancer après la mise à jour. Corrigez tout échec de connexion avant de poursuivre. Lorsque vous êtes prêt à restreindre l’accès, effacez les autorisations de trafic sortant de la sandbox et bloquez le trafic DNS sortant sur le port `53`, en UDP et en TCP. La mise à jour ne modifie pas l’ingress déclaré. Pour rejeter une écriture obsolète de l’état souhaité, lisez la configuration actuelle et transmettez son `etag` avec la mise à jour : ```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 @- ``` La réponse contient le `NetworkConfig` mis à jour. La sandbox continue de s'exécuter avec le même ID et le même état de processus. Le trafic requis par la plateforme, comme l'accès autorisé au stockage sur d'autres ports, peut rester disponible. `denyEgress` n'assure pas une isolation réseau complète. Utilisez un masque explicite pour effacer une liste. Une liste de trafic sortant vide, avec `denyEgress` non défini ou défini sur `false`, rétablit la valeur par défaut de la politique. Elle ne signifie pas que tout le trafic est refusé. ## Vérifier le résultat Remplacez `[SANDBOX-ID]` par l’ID obtenu lors de la création, puis inspectez la sandbox : ```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]"}' ``` Vérifiez que la sandbox reste à l’état `RUNNING`, qu’elle référence toujours le même `spec.networkConfigId` et qu’elle renvoie les valeurs mises à jour de `status.effectiveEgress`, `status.effectiveIngress` et `status.effectiveDnsEgress`. La réponse JSON peut omettre les champs répétés vides. Relancez les sondes de connexion qui réussissaient avant la mise à jour. Vérifiez que les nouvelles connexions HTTPS sortantes vers les deux hôtes précédemment autorisés échouent et que la charge de travail existante continue de s’exécuter. Écartez les causes d’échec sans rapport, comme une destination indisponible, avant de considérer l’échec d’une sonde comme la preuve de l’application des règles. Les champs de statut reflètent la dernière mise à jour réussie telle qu’elle a été enregistrée, et non une mesure en temps réel de l’application. > [!WARNING] > > Une mise à jour peut enregistrer la configuration souhaitée avant que son application soit terminée. Une défaillance temporaire peut laisser certaines modifications appliquées sans rétablir l’application précédente. Lisez la configuration actuelle, réappliquez les règles prévues avec son `etag` actuel et vérifiez le trafic avant de vous fier à une restriction. En cas de rejet définitif par l’exécuteur, l’API tente de restaurer la configuration souhaitée précédente. Voir [Comportement d’application et cycle de vie](https://docs.coreweave.com/fr/products/sandboxes/reference/network-configs.md#apply-behavior-and-lifecycle). En cas de non-correspondance de l’`etag`, vous devez relire la configuration et réconcilier les modifications simultanées. ## Réutiliser ou supprimer la configuration Lorsque la sandbox se termine, une configuration créée par l’appelant devient disponible pour être réutilisée. Son champ `status.sandboxId` peut conserver brièvement l’ancien ID, le temps que le nettoyage s’achève. Vous pouvez associer la configuration à une nouvelle sandbox ou la supprimer : ```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}' ``` La suppression échoue tant qu’une sandbox dont l’état n’est pas terminal utilise la configuration. Les configurations créées par la plateforme sont supprimées automatiquement une fois leur sandbox arrêtée. Pour reproduire l’intention réseau sur une autre sandbox, copiez le `spec` de la configuration dans une nouvelle configuration ou dans l’entrée de création en ligne. Copier `GetSandbox.spec` revient à copier l’ID de la configuration, et non un ensemble de règles indépendant. ## Modifications prises en charge et limites Les modifications et limites suivantes s’appliquent aux politiques réseau dynamiques : * Vous pouvez mettre à jour les autorisations de destination du trafic sortant, les sources d’ingress déclarées pour les services `CUSTOM` existants, ainsi que `denyEgress`, `denyIngress` et `dnsEgress`. Les règles doivent rester dans les limites de la politique de l’exécuteur. * Les ports et la visibilité des services restent des paramètres définis à la création. Voir [Points de terminaison publics](https://docs.coreweave.com/fr/products/sandboxes/public-endpoints.md). * Les autorisations de nom d’hôte HTTPS restent limitées au HTTPS sur le port TCP `443`. Vous ne pouvez modifier les autorisations de nom d’hôte à chaud que sur une Sandbox créée avec au moins une autorisation `httpsHostname`. Pour ajouter des autorisations de nom d’hôte à une Sandbox créée sans ce type d’autorisation, créez une nouvelle Sandbox. * Certaines Sandbox plus anciennes ne permettent pas de modifier leurs autorisations de nom d’hôte à chaud, y compris pour les supprimer. Si la mise à jour est rejetée avec `CWSANDBOX_INVALID_REQUEST`, créez une nouvelle Sandbox avec les autorisations requises. * L’exécuteur doit prendre en charge les autorisations de nom d’hôte HTTPS. S’il ne peut pas les appliquer, les requêtes qui les ajoutent ou les modifient renvoient `CWSANDBOX_INVALID_REQUEST`. Pour les champs de ressource, les masques de mise à jour et la gestion des erreurs, consultez la [Référence de l’API NetworkConfig](https://docs.coreweave.com/fr/products/sandboxes/reference/network-configs.md).