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

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

​
Ce qu’une politique peut contraindre

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

​
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 15 octobre 2026