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

# Aperçu des politiques

> Comment une sandbox est résolue par rapport à la politique qui régit son cluster, et ce qu’une politique peut contraindre.

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, qui est obligatoire : la posture de sécurité est donc toujours déclarée par un administrateur, et jamais choisie par la plateforme.

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

<h2 id="how-a-sandbox-resolves-against-a-policy">
  Résolution d’un sandbox par rapport à une politique
</h2>

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 a bien un sens. Elle déclare une posture entièrement permissive, sans valeurs par défaut de base ni contraintes, tout en laissant s’appliquer les gates de sécurité au niveau de la plateforme.

<h2 id="what-a-policy-can-constrain">
  Ce qu’une politique peut contraindre
</h2>

Les contraintes sont regroupées selon ce qu’elles régissent. Chaque groupe est facultatif, et un groupe non défini n’impose aucune contrainte de ce type.

| Groupe | Régit |
| - | - |
| `resources` | Les minimums, maximums, valeurs par défaut et plafonds de CPU et de mémoire, ainsi que le caractère obligatoire ou non des limites. |
| `image` | Les registres et les images qu’une sandbox peut exécuter. |
| `network` | Le trafic sortant et l’ingress qu’une sandbox peut demander, et ce qu’elle obtient lorsqu’elle ne demande rien. |
| `security` | Les conteneurs privilégiés, les capacités Linux, les profils seccomp, les namespace de l’hôte et les classes de runtime. |
| `instance` | Les types d’instance de nœud sur lesquels une sandbox peut être placée. |
| `lifecycle` | La durée de vie maximale d’une sandbox. |
| `metadata` | Les préfixes d’annotation refusés. |
| `volumes` | Les supports de stockage autorisés et la taille maximale des volumes. |

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.

<h2 id="what-changed-from-profiles">
  Ce qui a changé par rapport aux profils
</h2>

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.

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

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.

<h2 id="where-reusable-configuration-lives">
  Où se trouve la configuration réutilisable
</h2>

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](/fr/products/sandboxes/profiles/templates) pour connaître le flux de travail et découvrir des exemples complets de modèles.

<h2 id="see-also">
  Voir aussi
</h2>

* [Architecture des bacs à sable](/fr/products/sandboxes/architecture) : les ressources qui composent une sandbox et la passerelle par laquelle transite chaque requête.
* [Déployer et gérer un runner](/fr/products/sandboxes/operations/managed-runners) : le cycle de vie de l’exécuteur et la configuration qu’il embarque.
* [Aperçu de l’API du plan de contrôle](/fr/products/sandboxes/reference/control-plane-api) : authentification, masques de champs, signaux de pulsation et contrat des points de terminaison.