> ## 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.
# Exemples de politiques
> Documents de politique complets pour cinq postures de cluster courantes : science des données, agents, CI et workers en arrière-plan.
Cette page rassemble cinq politiques complètes correspondant à des postures de cluster courantes, pour que vous puissiez partir d’un document fonctionnel plutôt que d’en rédiger un de toutes pièces.
Un cluster ne possède qu’une seule politique : ces exemples sont donc des alternatives, et non des éléments à combiner. Choisissez la posture qui correspond à l’usage prévu du cluster, puis adaptez-la. Chaque exemple est un document de politique complet : appliquez-le avec `cwic sandbox runner policy edit [RUNNER-ID] -f policy.json`, ou transmettez-le dans le champ `policy` d’une requête de mise à jour de l’exécuteur. Remplacez `[RUNNER-ID]` par l’ID de l’exécuteur dont vous souhaitez modifier la politique, et, dans les exemples de registre d’images, remplacez `[GITHUB-ORG]` par le nom de votre organisation ou de votre utilisateur GitHub Container Registry.
Pour un guide pas à pas détaillant chaque champ, voir [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure).
Cluster GPU de science des données
Un cluster conçu pour le travail de longue durée propre à chaque utilisateur : des ressources de calcul généreuses, des nœuds GPU et un accès à Internet pour récupérer des datasets et des paquets, à l’exception du point de terminaison des métadonnées d’instance, qui reste bloqué.
```json title="policy.json" theme={"system"}
{
"displayName": "Data science, GPU",
"constraints": {
"resources": {
"defaultCpu": "4",
"defaultMemory": "16Gi",
"maxCpu": "16",
"maxMemory": "128Gi",
"maxGpuCount": "2",
"requireLimits": true
},
"instance": { "allowedInstanceTypes": ["h100"] },
"image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
"network": {
"allowedEgress": [
{ "cidr": { "cidr": "0.0.0.0/0", "except": ["169.254.169.254/32"] } }
],
"defaultEgress": [
{ "cidr": { "cidr": "0.0.0.0/0", "except": ["169.254.169.254/32"] } }
]
},
"security": {
"allowPrivileged": false,
"allowedRuntimeClasses": ["kata-qemu", "cw-kata-nvidia-gpu"],
"defaultCpuRuntimeClass": "kata-qemu",
"defaultGpuRuntimeClass": "cw-kata-nvidia-gpu",
"allowedSeccompProfiles": ["RuntimeDefault"]
},
"lifecycle": { "defaultLifetimeSeconds": 86400 }
}
}
```
Les deux classes de runtime sont listées, car `allowedRuntimeClasses` applique un refus par défaut. Une sandbox ne peut épingler qu’une classe que vous avez explicitement nommée, et les deux valeurs par défaut déterminent celle qui lui est attribuée lorsqu’elle n’en épingle aucune.
Cluster d’agents partagé avec trafic sortant sur liste d’autorisation
Un cluster multilocataire destiné aux charges de travail d’agents. Les agents peuvent joindre un ensemble fixe de services en amont ainsi que les autres agents de l’organisation, mais rien d’autre.
```json title="policy.json" theme={"system"}
{
"displayName": "Agents, allowlisted egress",
"constraints": {
"resources": {
"defaultCpu": "1",
"defaultMemory": "2Gi",
"maxCpu": "4",
"maxMemory": "8Gi",
"requireLimits": true
},
"network": {
"allowedEgress": [
{ "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] },
{ "cidr": { "cidr": "151.101.0.0/16" }, "ports": [{ "port": 443 }] },
{ "tenant": "TENANT_SCOPE_SAME_ORG" }
],
"defaultEgress": [
{ "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
]
},
"security": {
"allowPrivileged": false,
"allowedRuntimeClasses": ["kata-qemu"],
"defaultCpuRuntimeClass": "kata-qemu",
"allowedSeccompProfiles": ["RuntimeDefault"]
},
"lifecycle": { "defaultLifetimeSeconds": 3600 }
}
}
```
Une sandbox qui ne déclare rien n’obtient que le premier CIDR. Une sandbox qui doit joindre d’autres Sandbox de l’organisation déclare elle-même la règle de tenant, et la politique l’autorise, car cette règle reste dans les limites de l’enveloppe.
Cluster CI éphémère
Durée de vie courte, taille réduite et périmètre restreint. Les Sandbox n’existent que le temps d’une exécution de tests.
```json title="policy.json" theme={"system"}
{
"displayName": "CI",
"constraints": {
"resources": {
"defaultCpu": "250m",
"defaultMemory": "512Mi",
"maxCpu": "2",
"maxMemory": "4Gi",
"requireLimits": true
},
"image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
"network": {
"allowedEgress": [
{ "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
],
"defaultEgress": [
{ "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
]
},
"security": {
"allowPrivileged": false,
"allowedRuntimeClasses": ["gvisor"],
"defaultCpuRuntimeClass": "gvisor",
"allowedSeccompProfiles": ["RuntimeDefault"]
},
"lifecycle": { "defaultLifetimeSeconds": 900 },
"volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "10Gi" }
}
}
```
C’est la valeur par défaut de 15 minutes qui fait tout l’intérêt de cette configuration : une tâche CI qui ne déclare rien s’arrête d’elle-même rapidement. La politique n’impose aucun plafond de durée de vie : les requêtes qui dépassent le maximum de la plateforme, fixé à 30 jours, sont rejetées à la création, et toute valeur inférieure est acceptée. Définissez donc `max_lifetime_seconds` dans la requête de création lorsqu’une limite stricte par tâche est nécessaire.
Exécution isolée dans une VM sans trafic sortant par défaut
Cette politique exige une isolation par VM et ne fournit aucune règle de trafic sortant par défaut. Elle bloque le trafic DNS sortant sur le port 53 (UDP/TCP), mais autorise les Sandbox à déclarer d’autres règles de trafic sortant, puisque `allowedEgress` est vide.
```json title="policy.json" theme={"system"}
{
"displayName": "VM-isolated execution",
"constraints": {
"resources": {
"defaultCpu": "500m",
"defaultMemory": "512Mi",
"maxCpu": "2",
"maxMemory": "2Gi",
"requireLimits": true
},
"image": { "allowedImages": ["ghcr.io/[GITHUB-ORG]/sandbox-base:pinned"] },
"network": {
"allowedEgress": [],
"defaultEgress": [],
"dnsEgress": "DNS_EGRESS_MODE_DENY"
},
"security": {
"allowPrivileged": false,
"allowedCapabilities": [],
"allowedRuntimeClasses": ["kata-qemu"],
"defaultCpuRuntimeClass": "kata-qemu",
"allowedSeccompProfiles": ["RuntimeDefault"]
},
"lifecycle": { "defaultLifetimeSeconds": 300 },
"metadata": { "maxAnnotationCount": 0 },
"volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "5Gi" }
}
}
```
Cette politique n’applique pas une isolation réseau complète. Une liste `allowedEgress` vide autorise tout de même les règles de destination explicites, et l’accès au stockage de la plateforme est accordé séparément. `dnsEgress` bloque le port sortant 53, mais ne bloque pas le DNS transitant par d’autres protocoles autorisés, comme HTTPS.
`allowedImages` épingle une image précise plutôt qu’un registre entier, de sorte qu’une sandbox ne peut pas sélectionner n’importe quelle image d’un registre de confiance.
Cluster de workers internes
Des workers d’arrière-plan à exécution longue, auxquels les autres Sandbox de l’organisation accèdent via un service, et qui disposent d’un accès sortant pour les appels d’API tiers.
```json title="policy.json" theme={"system"}
{
"displayName": "Internal workers",
"constraints": {
"resources": {
"defaultCpu": "1",
"defaultMemory": "2Gi",
"maxCpu": "8",
"maxMemory": "16Gi",
"requireLimits": true
},
"image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
"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" }]
},
"security": {
"allowPrivileged": false,
"allowedRuntimeClasses": ["kata-qemu"],
"defaultCpuRuntimeClass": "kata-qemu",
"allowedSeccompProfiles": ["RuntimeDefault"]
},
"lifecycle": { "defaultLifetimeSeconds": 604800 }
}
}
```
Le trafic sortant est limité de sorte que les workers puissent atteindre l’internet public et les Sandbox de même niveau au sein de l’organisation, à l’exclusion de l’espace d’adressage privé et de l’adresse des métadonnées.
Cet exemple configure uniquement le trafic sortant. Pour restreindre l’accès entrant aux ports dont la visibilité est `CUSTOM`, ajoutez `allowedIngress` et, si nécessaire, `defaultIngress`. Voir [Restreindre l’accès réseau](/fr/products/sandboxes/profiles/configure#constrain-network-access).
Fixer les valeurs par défaut de l’administrateur avec la couche de base
Chacune des politiques ci-dessus peut également comporter un fragment `base` : des éléments joints par l’administrateur et appliqués à chaque sandbox de l’exécuteur, quelles que soient ses demandes. Cette variante de la politique interne des workers impose à tous les Sandbox la sélection des nœuds, un secret de récupération d’image pour le registre privé et une étiquette d’attribution des coûts.
```json title="policy.json" theme={"system"}
{
"displayName": "Internal workers, pinned scheduling",
"base": {
"spec": {
"nodeSelector": { "workload": "sandbox" },
"tolerations": [
{ "key": "sandbox-only", "operator": "Exists", "effect": "NoSchedule" }
],
"imagePullSecrets": [{ "name": "regcred" }]
},
"metadata": {
"labels": { "cost-center": "sandboxes" }
}
},
"constraints": {
"resources": {
"defaultCpu": "1",
"defaultMemory": "2Gi",
"maxCpu": "8",
"maxMemory": "16Gi",
"requireLimits": true
},
"image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
"security": {
"allowPrivileged": false,
"allowedRuntimeClasses": ["kata-qemu"],
"defaultCpuRuntimeClass": "kata-qemu",
"allowedSeccompProfiles": ["RuntimeDefault"]
},
"lifecycle": { "defaultLifetimeSeconds": 604800 }
}
}
```
Le fragment `base` est un sous-ensemble de la spécification de pod Kubernetes dont les clés sont en camelCase, contrairement aux champs de contrainte qui l’entourent ; les clés inconnues sont rejetées. Il n’accepte que les éléments d’ordonnancement et la plomberie d’exécution : `nodeSelector`, `tolerations`, `imagePullSecrets`, `volumes`, `topologySpreadConstraints`, `hostAliases`, les paramètres DNS, une seule entrée `containers` limitée à `name`, `env`, `envFrom`, `volumeMounts` et `volumeDevices`, ainsi que les libellés et annotations de pod. Les champs sensibles pour la sécurité sont rejetés : `securityContext`, `runtimeClassName`, `initContainers`, `affinity`, les namespace de l’hôte, les volumes `hostPath`, les comptes de service autres que celui par défaut, ainsi que `namespace`, qui reste géré par l’exécuteur. Les aspects typés, comme la durée de vie, les images et le trafic sortant, relèvent de `constraints` et non de `base`.
Sur un cluster CKS, les [éléments joints aux modèles](/fr/products/sandboxes/profiles/templates#cks-only-pod-attachments) spécialisent ce fragment pour chaque modèle : `imagePullSecrets` et `tolerations` sont fusionnés par union et dédupliqués, les autres listes sont concaténées, les clés de map sont remplacées une à une, et tout conflit de noms identiques entraîne le rejet de la création. Pour connaître le statut d’application actuel de `base`, consultez [la couche de base](/fr/products/sandboxes/profiles/configure#the-base-layer).
Varier la posture selon les clusters
Comme une politique appartient à un cluster, des postures différentes correspondent à des clusters différents, et non à des documents différents sur un même cluster. Une équipe qui a besoin à la fois d’un environnement de science des données ouvert et d’un environnement d’exécution verrouillé exploite deux clusters et attribue à chacun la politique adaptée.
Pour faire varier une dimension selon la région, appliquez la même politique à chaque cluster en modifiant les valeurs propres à chaque région. Il n’existe aucun document de politique partagé ou hérité : conservez donc la source de vérité dans un système de gestion de versions et appliquez-la cluster par cluster.
Voir aussi
* [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure) : tous les groupes de contraintes, avec les champs utilisés dans ces exemples.
* [Aperçu des politiques](/fr/products/sandboxes/profiles/profiles) : comment une sandbox est résolue en fonction d’une politique.
* [Entraînement RL agentique](/fr/products/sandboxes/client/guides/rl-training) : fonctions de récompense et rollouts d’agents à plusieurs tours de conversation, avec du code Python fonctionnel.
* [Déployer et gérer un exécuteur](/fr/products/sandboxes/operations/managed-runners) : le reste de la configuration de l’exécuteur.