> ## 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. # Configurer une politique de sandbox > Définissez les contraintes qui encadrent ce que les bacs à sable d’un cluster peuvent demander, ainsi que les valeurs par défaut dont ils héritent. Cette page explique comment rédiger la politique qui régit les bacs à sable d’un cluster : encadrer le calcul, les images, l’accès réseau et la posture de sécurité, et définir les valeurs par défaut dont hérite chaque sandbox. Elle s’adresse aux administrateurs qui gèrent les exécuteurs. Une politique est portée par l’exécuteur : pour la rédiger, vous mettez donc à jour l’exécuteur. Il n’existe ni ressource de politique distincte, ni point de terminaison dédié aux politiques. Pour savoir comment une sandbox est résolue par rapport à une politique, consultez [Aperçu des politiques](/fr/products/sandboxes/profiles/profiles).

Avant de commencer

Vous devez disposer du rôle **Sandbox Admin** dans votre organisation. Sans ce rôle, toute tentative de lecture ou d’écriture d’une politique renvoie `PermissionDenied`. Pour utiliser les exemples de CLI, installez la [CoreWeave Intelligent CLI](https://github.com/coreweave/cwic) et authentifiez-vous. Pour utiliser les exemples REST, vous avez besoin d’un jeton API CoreWeave. Dans les exemples, `$TOKEN` désigne ce jeton et `prod-us-east-1` désigne l’exécuteur. Chaque exécuteur possède exactement une politique, et cette politique est obligatoire. Une politique sans base ni contraintes est valide et déclare une posture entièrement permissive. Un opérateur définit ainsi toujours la posture de manière explicite, au lieu d’en hériter par inadvertance.

Lire la politique actuelle

Partez de la configuration actuelle de l’exécuteur plutôt que d’un document vide. ```bash theme={"system"} cwic sandbox runner policy get prod-us-east-1 ``` Ajoutez `describe` pour obtenir une vue détaillée, qui signale explicitement l’état non configuré lorsqu’un exécuteur n’a pas de politique : ```bash theme={"system"} cwic sandbox runner policy describe prod-us-east-1 ``` Avec `-o json`, un exécuteur qui n’a jamais été configuré renvoie `null` et non `{}`, ce qui permet aux outils d’automatisation de distinguer « jamais configuré » de « configuré et permissif ». ```bash title="Lire un exécuteur et sa politique" theme={"system"} curl https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1 \ -H "Authorization: Bearer $TOKEN" ```

Mettre à jour une politique

Une politique est un champ de l’exécuteur : vous la définissez donc en mettant à jour l’exécuteur avec le masque de mise à jour `policy`. **Une mise à jour de politique remplace toujours l’intégralité du document.** Seul `policy` est implémenté comme chemin de masque de mise à jour : vous ne pouvez donc pas modifier un seul groupe de contraintes en laissant le reste intact. Lisez la politique actuelle, modifiez ce dont vous avez besoin, puis renvoyez le document complet. Modifiez la politique dans `$EDITOR`, prérempli avec le document actuel de l’exécuteur : ```bash theme={"system"} cwic sandbox runner policy edit prod-us-east-1 ``` Appliquez un document depuis un fichier, ou depuis stdin avec `-` : ```bash theme={"system"} cwic sandbox runner policy edit prod-us-east-1 -f policy.yaml ``` Avec `-f`, `cwic` lit la révision actuelle de l’exécuteur au moment de la soumission : un fichier modifié à partir d’une lecture antérieure peut donc écraser la modification d’un autre administrateur. Pour figer la révision sur laquelle repose votre fichier, capturez la politique et son `etag` à partir d’une seule et même lecture de l’exécuteur : ```bash theme={"system"} cwic sandbox runner get prod-us-east-1 -o json > runner.json jq '.[0].policy' runner.json > policy.json ``` Modifiez `policy.json`, puis soumettez-le avec l’`etag` issu de cette même lecture : ```bash theme={"system"} cwic sandbox runner policy edit prod-us-east-1 -f policy.json \ --etag "$(jq -r '.[0].etag' runner.json)" ``` Prenez l’`etag` de la lecture qui a produit le document, jamais celui d’une lecture ultérieure. `policy get` exporte la politique sans son `etag`, et un `policy describe` exécuté après l’export peut renvoyer un jeton plus récent, qui passe la vérification et permet à votre fichier d’écraser la modification effectuée entre-temps. L’onglet curl et [Remplacer la politique](/fr/products/sandboxes/operations/managed-runners#example-replace-the-policy) capturent de la même manière les deux à partir d’une seule réponse. Le mode éditeur ne nécessite aucune option, car il envoie l’`etag` lu pour préremplir l’éditeur. Pour partir d’une structure de base plutôt que du document actuel, affichez un modèle : ```bash theme={"system"} cwic sandbox runner policy edit prod-us-east-1 --print-template ``` Vérifiez un document avant de l’envoyer : ```bash theme={"system"} cwic sandbox runner policy validate -f policy.yaml ``` Remplacez `[ETAG]` par la valeur `etag` de la lecture sur laquelle repose cette modification. Une valeur obsolète échoue avec `FAILED_PRECONDITION` et ne modifie rien. Voir [Remplacer la politique](/fr/products/sandboxes/operations/managed-runners#example-replace-the-policy). ```bash title="Définir la politique d’un exécuteur" 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]" }' ``` Trois règles s’appliquent à toute écriture de politique : * **La durée de vie est bornée par la plateforme, et non par la politique.** Une politique fournit uniquement `constraints.lifecycle.defaultLifetimeSeconds`, utilisé lorsqu’une requête de création ne précise pas de durée de vie. À la création, la plateforme rejette les durées de vie supérieures à son maximum, actuellement fixé à 30 jours. Les versions antérieures des politiques comportaient un plafond `maxLifetimeSeconds` ; la version actuelle de `cwic` rejette les documents qui le contiennent encore. * **Une politique configurée ne peut pas être effacée.** Il n’existe aucune opération de suppression, et l’API rejette toute mise à jour qui définit la politique sur null. Pour assouplir une posture, remplacez le document par un document plus permissif. * **La taille d’un document de politique est plafonnée à 256 Kio** une fois encodé. Une écriture de politique est une opération de lecture-modification-écriture, vérifiée par rapport à l’`etag` de la lecture de l’exécuteur sur laquelle repose votre modification. Si un autre administrateur a mis à jour la politique depuis cette lecture, l’API rejette votre écriture avec `FAILED_PRECONDITION` et ne modifie rien. Relisez l’exécuteur, réappliquez votre modification au document renvoyé, puis soumettez-le de nouveau avec le nouvel `etag`. Récupérer un nouvel `etag` et renvoyer votre document inchangé permet de passer la vérification, mais écrase la modification de l’autre administrateur, car l’écriture remplace toujours l’intégralité du document. Pour des exemples de durée de vie et les différences entre le mode sans serveur et CKS, consultez [Exécuter des bacs à sable de longue durée](/fr/products/sandboxes/long-running-sandboxes). Les modifications de politique s’appliquent aux bacs à sable créés après la mise à jour. Les bacs à sable en cours d’exécution conservent la politique résolue lors de leur lancement. Par ailleurs, la copie mise en cache par la passerelle peut accuser un bref retard : un placement effectué quelques instants après une écriture peut donc encore être résolu selon la politique précédente. Les commandes de politique utilisent l’API v1 en lecture et en écriture, tandis que les autres commandes `cwic sandbox runner` et `cwic sandbox profile` utilisent toujours v1beta2. Les deux passent par le même `--api-url`.

Définir une politique par défaut pour les nouveaux exécuteurs

CoreWeave configure une politique par défaut pour les nouveaux exécuteurs dans son service hébergé. Les autres déploiements peuvent définir leur propre politique par défaut. La passerelle enregistre cette politique lorsqu’un exécuteur se connecte ou lorsque le placement v1 sélectionne pour la première fois un exécuteur dépourvu de politique. Un exécuteur qui possède déjà une politique la conserve. La politique par défaut est définie dans la configuration de l’infrastructure de la passerelle, sous `gateway.infraConfig.default_runner_policy`, et toute modification nécessite un redémarrage de la passerelle. Il n’existe aucune politique par défaut intégrée. Lorsque ce paramètre est absent ou nul, rien n’est enregistré et la sandbox est toujours rejetée avec l’erreur `CWSANDBOX_POOL_POLICY_NOT_CONFIGURED`. Avant de vous appuyer sur ce mécanisme, tenez compte de deux comportements : * **La politique par défaut est un instantané, pas un lien.** Une fois appliquée à un exécuteur, elle devient une politique d’exécuteur ordinaire. Les modifications ultérieures de `default_runner_policy` ne sont pas répercutées sur les exécuteurs qui en possèdent déjà une. Mettez ces derniers à jour avec `UpdateManagedRunner`. * **Une politique par défaut non valide compromet la création.** La passerelle valide la politique configurée au démarrage. Si la validation échoue, la passerelle démarre tout de même, mais la création de sandboxes échoue avec l’erreur `CWSANDBOX_SERVERLESS_MISCONFIGURED`.

Limiter les ressources de calcul

`resources` fixe les limites de ce qu’un conteneur peut demander et fournit les valeurs appliquées par défaut lorsqu’une sandbox ne demande rien. ```json theme={"system"} { "constraints": { "resources": { "minCpu": "500m", "maxCpu": "8", "defaultCpu": "2", "minMemory": "1Gi", "maxMemory": "32Gi", "defaultMemory": "4Gi", "maxGpuCount": "2", "requireLimits": true } } } ``` Définissez `requireLimits` sur `true` pour rejeter les bacs à sable qui ne déclarent pas à la fois une limite de CPU et une limite de mémoire. Utilisez `cpuCeiling` et `memoryCeiling` pour plafonner le total résolu d’une sandbox, ce qui s’avère utile lorsque la couche de base ajoute ses propres conteneurs. `maxGpuCount` plafonne le nombre de GPU qu’une sandbox peut demander. Omettez-le pour n’appliquer aucun plafond. Définissez-le sur `0` pour rejeter toute demande de GPU : c’est ainsi que l’on définit un pool sans GPU. Toute demande supérieure au plafond échoue avec l’erreur `CWSANDBOX_RESOURCE_CEILING_EXCEEDED`.

Restreindre les images

`image` limite les sources autorisées pour les images de sandbox. Un groupe vide autorise n’importe quelle image. Remplacez `[GITHUB-ORG]` par le nom de votre organisation ou votre nom d’utilisateur GitHub Container Registry. ```json theme={"system"} { "constraints": { "image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"], "allowedImages": ["ghcr.io/[GITHUB-ORG]/agent-base:2024.11"] } } } ```

Restreindre l’accès réseau

Les contraintes réseau fonctionnent comme une enveloppe. Lorsqu’une sandbox déclare du trafic sortant, la politique accepte ou rejette cette déclaration, sans jamais l’élargir. Lorsque la sandbox ne déclare aucun trafic sortant, la politique applique ses valeurs par défaut de trafic sortant, sauf si la sandbox définit `deny_egress`. Deux paramètres remplissent des rôles distincts : * `allowedEgress` est la liste d’autorisation du trafic sortant, vérifiée à la création d’une sandbox. Lorsqu’elle n’est pas vide, chaque règle déclarée par la sandbox doit s’y inscrire, et toute règle qui la dépasse est rejetée, et non restreinte. Une liste vide signifie que tout peut être déclaré. * `defaultEgress` détermine le comportement appliqué en l’absence de demande. Il ne s’applique que lorsque la sandbox ne déclare aucun trafic sortant propre et ne définit pas `deny_egress`. Toute déclaration le remplace entièrement. Une règle désigne une seule destination. Utilisez `cidr` avec d’éventuelles exclusions `except`, `tenant` pour une relation avec d’autres bacs à sable, `selector` pour des charges de travail sélectionnées par libellé, `httpsHostname` pour un nom d’hôte HTTPS, ou `any`. Des `ports` facultatifs permettent de restreindre davantage la règle. Les règles de nom d’hôte n’autorisent que le port TCP 443 et nécessitent un exécuteur qui les prend en charge. Elles ont leur place dans `allowedEgress` et dans les demandes des sandbox, et non dans `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" } ] } } } ``` L’exemple autorise l’internet public tout en excluant l’espace d’adressage privé et l’adresse des métadonnées d’instance, et permet aux bacs à sable de joindre d’autres bacs à sable de la même organisation. Une sandbox qui ne déclare aucune règle n’a accès qu’aux ressources de la même organisation. Les portées de tenant sont `TENANT_SCOPE_SAME_USER` et `TENANT_SCOPE_SAME_ORG`. Une troisième valeur, `TENANT_SCOPE_SANDBOX_NETWORK`, n’est pas encore prise en charge : toute règle de trafic sortant qui l’utilise est rejetée. L’ingress utilise `allowedIngress` et `defaultIngress` pour les ports dont la visibilité est `CUSTOM`. Une liste d’autorisation non vide s’impose à chaque règle d’ingress déclarée. Lorsqu’une sandbox expose un port `CUSTOM` sans déclarer de règles d’ingress, `defaultIngress` s’applique, sauf si la sandbox définit `deny_ingress`. Les règles d’ingress explicites remplacent cette valeur par défaut. Les règles d’ingress acceptent `cidr`, `tenant` ou `any` ; elles n’acceptent pas de sources fondées sur des noms. Définissez `denyHttpsHostnameRules` pour rejeter les règles HTTPS fondées sur des noms d’hôte. Cela ne bloque ni les requêtes DNS ni le trafic HTTPS autorisé par des règles CIDR. Définissez `dnsEgress` sur `DNS_EGRESS_MODE_DENY` pour bloquer le trafic sortant sur le port UDP/TCP 53. Si ce paramètre est omis, l’accès DNS au résolveur de la plateforme est autorisé. L’accès au DNS et au stockage de la plateforme est accordé indépendamment des règles de destination. Voir [Contraintes réseau](/fr/products/sandboxes/reference/profile#networkconstraints) pour les règles de confinement et le comportement DNS.

Restreindre la posture de sécurité

`security` régit les privilèges dans l’invité ainsi que le niveau d’isolation dans lequel la sandbox s’exécute. ```json theme={"system"} { "constraints": { "security": { "allowPrivileged": false, "allowedCapabilities": ["NET_BIND_SERVICE"], "allowedSeccompProfiles": ["RuntimeDefault"], "allowedRuntimeClasses": ["kata-qemu"], "defaultCpuRuntimeClass": "kata-qemu" } } } ``` `allowedRuntimeClasses` applique un refus par défaut (fail closed). Une liste vide ou absente n’autorise aucun épinglage de classe de runtime : un sandbox ne peut donc sélectionner une classe que si vous l’ajoutez explicitement à la liste. Définissez `defaultCpuRuntimeClass` et `defaultGpuRuntimeClass` pour choisir la classe attribuée à un sandbox lorsqu’il n’en épingle aucune.

Restreindre les instances, la durée de vie, les métadonnées et les volumes

Les groupes restants sont plus réduits. | Groupe | Champs | Effet | | - | - | - | | `instance` | `allowedInstanceTypes` | Restreint les types d’instance de nœud sur lesquels une sandbox peut être placée. | | `lifecycle` | `defaultLifetimeSeconds` | Durée de vie attribuée à une sandbox qui n’en demande aucune. Le maximum de la plateforme, actuellement fixé à 30 jours, s’applique à toutes les sandboxes ; `maxLifetimeSeconds` a été retiré du document de politique et est désormais rejeté. | | `metadata` | `deniedAnnotationPrefixes`, `maxAnnotationCount` | Rejette les clés d’annotation selon leur préfixe et plafonne le nombre d’annotations qu’une sandbox peut définir. `0` signifie aucune limite. | | `volumes` | `allowedMedia`, `maxSize` | Restreint les supports de stockage et plafonne la taille de chaque volume. Omettez `STORAGE_MEDIUM_MEMORY` pour interdire les volumes en RAM. | ```json theme={"system"} { "constraints": { "lifecycle": { "defaultLifetimeSeconds": 3600 }, "volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "100Gi" } } } ```

La couche de base

Les contraintes délimitent ce qu’une sandbox peut demander. La couche `base` fournit ce que chaque sandbox reçoit sans avoir à le demander : des valeurs par défaut et des éléments joints tels que l’ordonnanceur, les sélecteurs de nœuds, les tolérances, les comptes de service et les secrets d’extraction d’image. Sa forme dépend du runtime de l’exécuteur ; sur un exécuteur Kubernetes, il s’agit d’un fragment de spécification de pod.

Étapes suivantes

* [Aperçu des politiques](/fr/products/sandboxes/profiles/profiles) : comment un sandbox est résolu par rapport à une politique, et ce qui a changé par rapport aux profils. * [Déployer et gérer un runner](/fr/products/sandboxes/operations/managed-runners) : le cycle de vie du runner et ses autres paramètres de configuration. * [Aperçu de l’API du plan de contrôle](/fr/products/sandboxes/reference/control-plane-api) : authentification, masques de champs et contrat des points de terminaison.