Skip to main content
Une politique définit la gouvernance qu’un administrateur applique aux bacs à sable d’un cluster. Elle associe une couche de base permissive de valeurs par défaut, dont hérite chaque sandbox, à des contraintes typées qui encadrent ce qu’une sandbox peut demander. Chaque cluster est régi par une seule politique. Dans son service hébergé, CoreWeave fournit une politique par défaut pour les nouveaux exécuteurs, que les administrateurs peuvent personnaliser. Voir Définir une politique par défaut pour les nouveaux exécuteurs. Les utilisateurs ne sélectionnent pas de politique et n’ont même pas besoin de savoir qu’elle existe. L’utilisateur décrit simplement la sandbox qu’il souhaite. Si la politique l’autorise, la sandbox est lancée. Si la politique en interdit une partie, la requête est rejetée et le message d’erreur précise ce qui a été refusé.

​
Résolution d’un sandbox par rapport à une politique

La résolution d’un sandbox se déroule en deux étapes.
  1. Base. La politique fournit les valeurs par défaut du runtime et les éléments joints, fusionnés dans l’ordre suivant : valeurs par défaut du runtime, puis base de la politique, puis spécification du bac à sable. Pour chaque valeur, c’est votre spécification qui l’emporte.
  2. Contraintes. Les limites typées sont validées par rapport à la spécification entièrement résolue. Une spécification qui enfreint une contrainte est rejetée, et jamais réécrite silencieusement.
L’ordre compte plus qu’il n’y paraît. Comme les contraintes valident la spécification résolue et non celle qui a été soumise, une valeur fournie par la base est vérifiée selon les mêmes critères qu’une valeur que vous avez vous-même fournie. Une politique vide est valide et ne fournit ni valeurs par défaut de base ni contraintes explicites. Les gates de sécurité de la plateforme continuent de s’appliquer, et en l’absence de liste d’autorisation des classes de runtime, aucun épinglage concret de runtime_class n’est autorisé. Voir SecurityConstraints.

​
Ce qu’une politique peut contraindre

Les contraintes sont regroupées selon ce qu’elles régissent. Chaque groupe est facultatif. L’omission d’un groupe n’ajoute aucune contrainte explicite de ce type, mais les gates de sécurité de la plateforme et les restrictions liées aux classes de runtime continuent de s’appliquer. Les contraintes réseau définissent des listes d’autorisation pour les accès qu’une sandbox peut demander. La sandbox déclare les accès dont elle a besoin, la politique valide cette demande au regard de ce que le cluster autorise, et elle définit par ailleurs le comportement appliqué en l’absence de demande. Déclarer des accès permet aussi à une sandbox de se restreindre elle-même, ce qui est utile lorsque vous exécutez un agent non fiable et souhaitez réduire sa portée en deçà de ce que la politique autoriserait.

​
Contrôles d’accès par IP source

Une politique peut également restreindre les requêtes API Sandbox en fonction de l’adresse source de l’appelant, via control_plane_access.source_ip_allowlist. La passerelle évalue ce contrôle lors de la sélection d’un exécuteur et avant toute nouvelle opération sur des bacs à sable existants, indépendamment des valeurs par défaut et des contraintes appliquées à la création. Les restrictions par IP source viennent compléter l’authentification et l’autorisation. Elles ne s’appliquent pas aux connexions établies directement avec les services exposés d’une sandbox. Pour la configuration et la récupération, voir Restreindre l’accès à l’API Sandbox par IP source.

​
Ce qui a changé par rapport aux profils

Les politiques remplacent les profils. La différence ne se limite pas au nom : deux changements méritent d’être bien compris avant de procéder à la migration. Les utilisateurs n’ont plus rien à choisir. Avec les profils, un utilisateur sélectionnait un profil par son nom, ce qui supposait de connaître les profils existants et de disposer de l’autorisation de les consulter. Lorsqu’aucun profil ne convenait, l’utilisateur devait demander à un administrateur d’en créer un. Avec les politiques, l’utilisateur déclare le sandbox dont il a besoin, et la plateforme soit l’autorise, soit explique ce qu’elle a refusé. La résolution s’effectue dans l’autre sens. Un profil écrasait les valeurs de votre spécification du bac à sable. Une politique fait l’inverse : votre spécification prévaut, et la politique encadre le résultat. Une configuration qu’un profil remplaçait silencieusement est désormais soit respectée, soit rejetée avec un motif.
L’inversion de la résolution constitue un changement de comportement, et non un simple renommage. Une requête qu’un profil aurait discrètement modifiée peut désormais être purement et simplement rejetée. Comparez les configurations de profils existantes aux groupes de contraintes avant de les migrer.
Les politiques sont définies par cluster. Il n’existe aucune granularité par équipe ou par utilisateur : tous les utilisateurs d’un cluster sont donc soumis à la même politique.

​
Où se trouve la configuration réutilisable

Les profils avaient une seconde fonction, au-delà de la gouvernance. Ils permettaient d’enregistrer facilement un ensemble d’options pour le réutiliser, à raison d’un profil par équipe ou par application. Ce rôle revient désormais aux modèles de sandbox, qui contiennent une spécification partielle et réutilisable du bac à sable, dont vous pouvez remplacer les valeurs lors de la création d’un sandbox. Les modèles ne font pas autorité : ils servent de point de départ, et seule la politique applique des règles. Consultez Modèles de sandbox pour connaître le flux de travail et découvrir des exemples complets de modèles.

​
Voir aussi

Dernière modification le 4 novembre 2026