Skip to main content
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.

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

​
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 :
Appliquez un document depuis un fichier, ou depuis stdin avec - :
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 :
Modifiez policy.json, puis soumettez-le avec l’etag issu de cette même lecture :
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 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 :
Vérifiez un document avant de l’envoyer :
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. 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.
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.

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

​
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

Dernière modification le 15 octobre 2026