Exemples de politiques

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.

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

policy.json

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

policy.json

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

policy.json

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

policy.json

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

policy.json

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

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.

policy.json

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

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 : tous les groupes de contraintes, avec les champs utilisés dans ces exemples.
Aperçu des politiques : comment une sandbox est résolue en fonction d’une politique.
Entraînement RL agentique : 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 : le reste de la configuration de l’exécuteur.

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Cluster GPU de science des données

Cluster d’agents partagé avec trafic sortant sur liste d’autorisation

Cluster CI éphémère

Exécution isolée dans une VM sans trafic sortant par défaut

Cluster de workers internes

Fixer les valeurs par défaut de l’administrateur avec la couche de base

Varier la posture selon les clusters

Voir aussi

​Cluster GPU de science des données

​Cluster d’agents partagé avec trafic sortant sur liste d’autorisation

​Cluster CI éphémère

​Exécution isolée dans une VM sans trafic sortant par défaut

​Cluster de workers internes

​Fixer les valeurs par défaut de l’administrateur avec la couche de base

​Varier la posture selon les clusters

​Voir aussi

Cluster GPU de science des données

Cluster d’agents partagé avec trafic sortant sur liste d’autorisation

Cluster CI éphémère

Exécution isolée dans une VM sans trafic sortant par défaut

Cluster de workers internes

Fixer les valeurs par défaut de l’administrateur avec la couche de base

Varier la posture selon les clusters

Voir aussi