Modifier l’accès réseau d’une Sandbox en cours d’exécution

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.
La prise en charge de NetworkConfig activée sur l’API qui dessert votre organisation. Voir Disponibilité et prérequis.
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.
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 à 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 :

Set the API token

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.

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"}
        ]
      }
    }
  }'

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 :

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
      }
    }
  }'

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

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 @-

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 :

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]"}'

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.

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

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}'

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

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Modifier l’accès réseau d’une Sandbox en cours d’exécution

Avant de commencer

Créer et associer une configuration réseau

Mettre à jour les règles de la sandbox en cours d’exécution

Vérifier le résultat

Réutiliser ou supprimer la configuration

Modifications prises en charge et limites

​Avant de commencer

​Créer et associer une configuration réseau

​Mettre à jour les règles de la sandbox en cours d’exécution

​Vérifier le résultat

​Réutiliser ou supprimer la configuration

​Modifications prises en charge et limites

Avant de commencer

Créer et associer une configuration réseau

Mettre à jour les règles de la sandbox en cours d’exécution

Vérifier le résultat

Réutiliser ou supprimer la configuration

Modifications prises en charge et limites