Configurer une politique de Sandbox

Cette page explique comment rédiger la politique qui régit les Sandbox d’un cluster : encadrer le calcul, les images, l’accès réseau et la posture de sécurité, et définir les valeurs par défaut dont hérite chaque Sandbox. Elle s’adresse aux administrateurs qui gèrent les exécuteurs. Les politiques prennent également en charge des contrôles d’accès par adresse IP source pour les requêtes API Sandbox. Une politique est portée par l’exécuteur : pour la rédiger, vous mettez donc à jour l’exécuteur. Il n’existe ni ressource de politique distincte, ni point de terminaison dédié aux politiques. Pour savoir comment une Sandbox est résolue par rapport à une politique, consultez Aperçu des politiques.

Avant de commencer

Vous devez disposer du rôle Sandbox Admin dans votre organisation. Sans ce rôle, toute tentative de lecture ou d’écriture d’une politique renvoie PermissionDenied.

The Sandbox Admin role controls runner settings across the organization. On runners using legacy v1beta2 profiles, this role can enable privileged profile settings. These settings include privileged containers, host namespaces, and mounts of the Node’s filesystem. These settings can give sandboxes Node access comparable to that of a cluster administrator and put co-located workloads at risk. The v1 policy’s allow_privileged setting governs in-guest privilege within the sandbox’s isolation boundary.

Pour utiliser les exemples de CLI, installez la CoreWeave Intelligent CLI et authentifiez-vous. Pour utiliser les exemples REST, vous avez besoin d’un jeton API CoreWeave. Dans les exemples, $TOKEN désigne ce jeton et prod-us-east-1 désigne l’exécuteur. Chaque exécuteur possède exactement une politique, et cette politique est obligatoire. 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 restent en vigueur et, en l’absence de liste d’autorisation des classes de runtime, aucune valeur concrète ne peut être épinglée pour runtime_class. Voir Restreindre la posture de sécurité.

Lire la politique actuelle

Partez de la configuration actuelle de l’exécuteur plutôt que d’un document vide.

CLI
curl

cwic sandbox runner policy get prod-us-east-1

Ajoutez describe pour obtenir une vue détaillée, qui signale explicitement l’état non configuré lorsqu’un exécuteur n’a pas de politique :

cwic sandbox runner policy describe prod-us-east-1

Avec -o json, un exécuteur qui n’a jamais été configuré renvoie null et non {}, ce qui permet aux outils d’automatisation de distinguer « jamais configuré » de « configuré et permissif ».

Lire un exécuteur et sa politique

curl https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1 \
  -H "Authorization: Bearer $TOKEN"

Mettre à jour une politique

Une politique est un champ de l’exécuteur : vous la définissez donc en mettant à jour l’exécuteur avec le masque de mise à jour policy. Une mise à jour de politique remplace toujours l’intégralité du document. Seul policy est implémenté comme chemin de masque de mise à jour : vous ne pouvez donc pas modifier un seul groupe de contraintes en laissant le reste intact. Lisez la politique actuelle, modifiez ce dont vous avez besoin, puis renvoyez le document complet.

CLI
curl

Modifiez la politique dans $EDITOR, prérempli avec le document actuel de l’exécuteur :

cwic sandbox runner policy edit prod-us-east-1

Appliquez un document depuis un fichier, ou depuis stdin avec - :

cwic sandbox runner policy edit prod-us-east-1 -f policy.yaml

Avec -f, cwic lit la révision actuelle de l’exécuteur au moment de la soumission : un fichier modifié à partir d’une lecture antérieure peut donc écraser la modification d’un autre administrateur. Pour figer la révision sur laquelle repose votre fichier, capturez la politique et son etag à partir d’une seule et même lecture de l’exécuteur :

cwic sandbox runner get prod-us-east-1 -o json > runner.json
jq '.[0].policy' runner.json > policy.json

Modifiez policy.json, puis soumettez-le avec l’etag issu de cette même lecture :

cwic sandbox runner policy edit prod-us-east-1 -f policy.json \
  --etag "$(jq -r '.[0].etag' runner.json)"

Prenez l’etag de la lecture qui a produit le document, jamais celui d’une lecture ultérieure. policy get exporte la politique sans son etag, et un policy describe exécuté après l’export peut renvoyer un jeton plus récent, qui passe la vérification et permet à votre fichier d’écraser la modification effectuée entre-temps. L’onglet curl et Remplacer la politique capturent de la même manière les deux à partir d’une seule réponse.Le mode éditeur ne nécessite aucune option, car il envoie l’etag lu pour préremplir l’éditeur.Pour partir d’une structure de base plutôt que du document actuel, affichez un modèle :

cwic sandbox runner policy edit prod-us-east-1 --print-template

Vérifiez un document avant de l’envoyer :

cwic sandbox runner policy validate -f policy.yaml

Remplacez [ETAG] par la valeur etag de la lecture sur laquelle repose cette modification. Une valeur obsolète échoue avec FAILED_PRECONDITION et ne modifie rien. Voir Remplacer la politique.

Définir la politique d’un exécuteur

curl -X PATCH "https://api.coreweave.com/v1/sandbox/managedRunners/prod-us-east-1?updateMask=policy" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "policy": {
      "displayName": "Shared agent pool",
      "constraints": {
        "resources": { "maxCpu": "8", "maxMemory": "32Gi", "requireLimits": true },
        "lifecycle": { "defaultLifetimeSeconds": 3600 }
      }
    },
    "etag": "[ETAG]"
  }'

Trois règles s’appliquent à toute écriture de politique :

La durée de vie est bornée par la plateforme, et non par la politique. Une politique fournit uniquement constraints.lifecycle.defaultLifetimeSeconds, utilisé lorsqu’une requête de création ne précise pas de durée de vie. À la création, la plateforme rejette les durées de vie supérieures à son maximum, actuellement fixé à 30 jours. Les versions antérieures des politiques comportaient un plafond maxLifetimeSeconds ; la version actuelle de cwic rejette les documents qui le contiennent encore.
Une politique configurée ne peut pas être effacée. Il n’existe aucune opération de suppression, et l’API rejette toute mise à jour qui définit la politique sur null. Pour assouplir une posture, remplacez le document par un document plus permissif.
La taille d’un document de politique est plafonnée à 256 Kio une fois encodé.

Une écriture de politique est une opération de lecture-modification-écriture, vérifiée par rapport à l’etag de la lecture de l’exécuteur sur laquelle repose votre modification. Si un autre administrateur a mis à jour la politique depuis cette lecture, l’API rejette votre écriture avec FAILED_PRECONDITION et ne modifie rien. Relisez l’exécuteur, réappliquez votre modification au document renvoyé, puis soumettez-le de nouveau avec le nouvel etag. Récupérer un nouvel etag et renvoyer votre document inchangé permet de passer la vérification, mais écrase la modification de l’autre administrateur, car l’écriture remplace toujours l’intégralité du document.

Pour des exemples de durée de vie et les différences entre le mode sans serveur et CKS, consultez Exécuter des Sandbox de longue durée. Les valeurs par défaut et les contraintes de politique sont résolues lors de la création d’un Sandbox. L’écriture d’une politique ne reconfigure pas automatiquement les Sandbox en cours d’exécution. Les nouveaux placements et les mises à jour réseau à chaud explicites sont résolus d’après la politique de l’exécuteur actuellement en cache dans la passerelle. Les contrôles d’accès par adresse IP source s’appliquent aussi bien aux nouvelles opérations sur les Sandbox existants qu’aux nouveaux placements. La politique mise en cache peut accuser un bref retard après une mise à jour.

Les commandes de politique utilisent l’API v1 en lecture et en écriture, tandis que les autres commandes cwic sandbox runner et cwic sandbox profile utilisent toujours v1beta2. Les deux passent par le même --api-url.

Restreindre l’accès à l’API Sandbox par adresse IP source

Utilisez control_plane_access.source_ip_allowlist pour restreindre les requêtes API Sandbox en fonction de l’adresse source. L’adresse source du client, telle qu’elle est observée, doit correspondre à une plage CIDR (classless inter-domain routing) IPv4 ou IPv6. La liste d’autorisation vient s’ajouter à l’authentification, aux autorisations de gestion des identités et des accès (IAM) et aux vérifications d’appartenance à l’organisation. Elle ne rend pas privé l’API endpoint partagé et ne restreint pas le trafic envoyé directement aux services exposés par une sandbox. Utilisez l’adresse publique de trafic sortant que CoreWeave observe pour le client qui envoie la requête API. Pour un client exécuté dans un Pod CoreWeave Kubernetes Service (CKS) qui utilise l’acheminement standard par traduction d’adresses réseau (NAT) publique, utilisez les plages NAT Egress de son Availability Zone. Pour un client connecté à votre réseau d’entreprise ou à votre réseau privé virtuel (VPN), utilisez les plages publiques de trafic sortant de votre organisation. Une adresse privée de Pod ou de poste de travail ne peut pas se substituer à l’adresse source observée. Pour ajouter une liste d’autorisation tout en conservant les autres paramètres de la politique de l’exécuteur, procédez comme suit :

Ouvrez la politique actuelle dans votre éditeur :
cwic sandbox runner policy edit prod-us-east-1
Le mode éditeur conserve l’etag obtenu lors de la lecture qui a ouvert le document. Ainsi, si un autre administrateur met à jour la politique entre-temps, sa modification provoque un conflit au lieu d’être écrasée.
Ajoutez le fragment suivant à la racine de la politique actuelle. Remplacez les valeurs de substitution par les CIDR publics de trafic sortant réellement utilisés par vos clients. Omettez toute famille d’adresses que vos clients n’utilisent pas. Conservez les autres champs de la politique :
control_plane_access: source_ip_allowlist: cidrs: - "[PUBLIC-IPV4-CIDR]" - "[PUBLIC-IPV6-CIDR]"
Enregistrez le document complet et quittez l’éditeur. Si l’API signale un etag obsolète, rouvrez la politique actuelle et appliquez de nouveau votre modification avant d’enregistrer.

La liste d’autorisation fonctionne comme suit :

En l’absence de source_ip_allowlist, aucune restriction d’adresse source n’est appliquée.
Si une liste d’autorisation est présente, l’adresse source observée doit correspondre à au moins un CIDR.
0.0.0.0/0 autorise toutes les adresses IPv4, et ::/0 toutes les adresses IPv6.
L’entrée est limitée à 256 CIDR et à 16 Kio de texte CIDR, avant normalisation. L’API met les préfixes sous forme canonique, supprime les doublons ainsi que les préfixes couverts par une entrée plus large.

Un champ source_ip_allowlist présent mais vide, y compris source_ip_allowlist: {}, refuse toutes les adresses sources publiques. Pour lever la restriction, supprimez le champ de la liste d’autorisation plutôt que de le vider.

Modifications de politique et comportement des requêtes

Une fois le cache des politiques convergé, la passerelle vérifie la liste d’autorisation mise à jour lors de la sélection d’un exécuteur et avant toute nouvelle opération sur des Sandbox existants. Cela inclut les lectures, les commandes, les transferts de fichiers, les opérations de cycle de vie, les snapshots et les requêtes de diffusion en continu. Les nouveaux flux, les flux repris et les requêtes transmises à une autre passerelle font l’objet de cette vérification. Les flux déjà établis restent connectés. Les requêtes de liste et de découverte omettent les ressources refusées en raison de l’adresse source. Si la passerelle ne parvient pas à évaluer une politique requise, la requête échoue plutôt que de renvoyer des ressources sans décision d’accès. Pour les requêtes autres que les reprises de flux, l’API distingue le refus lié à la source de l’indisponibilité de l’état de la politique :

Condition de la requête	Erreur
Une requête portant sur une sandbox existante est refusée en raison de la source, ou tous les candidats à la création par ailleurs adaptés sont refusés en raison de la source.	`PermissionDenied` avec `CWSANDBOX_SOURCE_IP_NOT_ALLOWED`.
La passerelle ne parvient pas à évaluer la politique requise. Pour une création, aucun candidat autorisé ne subsiste et au moins un candidat présente une décision d’accès indéterminée.	`Unavailable` avec `CWSANDBOX_ACCESS_POLICY_UNAVAILABLE`.

Lors de la reprise d’un flux, un refus lié à l’adresse source peut se traduire par une réponse SESSION_NOT_FOUND au sein du flux. Une politique d’accès indisponible renvoie toujours Unavailable avec CWSANDBOX_ACCESS_POLICY_UNAVAILABLE. Une requête de création peut néanmoins utiliser un autre exécuteur adapté qui autorise l’adresse source. Les vérifications d’authentification, d’adéquation des ressources et de capacité restent applicables.

Rétablir l’accès sans restriction de source

L’administration des politiques nécessite le rôle Sandbox Admin et n’est pas soumise à la liste d’adresses IP sources autorisées de l’exécuteur. Pour débloquer un accès verrouillé, ouvrez la politique actuelle à l’aide de la commande d’édition indiquée plus haut. Supprimez le champ source_ip_allowlist ou le champ control_plane_access qui le contient, puis enregistrez le document complet. Conservez les autres paramètres de la politique. Une fois que le cache des politiques a convergé, les nouvelles requêtes ne sont plus filtrées par adresse source. L’authentification et l’autorisation restent appliquées. Pour connaître les types de champs et les règles de validation, consultez control_plane_access dans la référence des stratégies.

Définir une politique par défaut pour les nouveaux exécuteurs

CoreWeave configure une politique par défaut pour les nouveaux exécuteurs dans son service hébergé. Les autres déploiements peuvent définir leur propre politique par défaut. La passerelle enregistre cette politique lorsqu’un exécuteur se connecte ou lorsque le placement v1 sélectionne pour la première fois un exécuteur dépourvu de politique. Un exécuteur qui possède déjà une politique la conserve. La politique par défaut est définie dans la configuration de l’infrastructure de la passerelle, sous gateway.infraConfig.default_runner_policy, et toute modification nécessite un redémarrage de la passerelle. Il n’existe aucune politique par défaut intégrée. Lorsque ce paramètre est absent ou nul, rien n’est enregistré et la sandbox est toujours rejetée avec l’erreur CWSANDBOX_POOL_POLICY_NOT_CONFIGURED. Avant de vous appuyer sur ce mécanisme, tenez compte de deux comportements :

La politique par défaut est un instantané, pas un lien. Une fois appliquée à un exécuteur, elle devient une politique d’exécuteur ordinaire. Les modifications ultérieures de default_runner_policy ne sont pas répercutées sur les exécuteurs qui en possèdent déjà une. Mettez ces derniers à jour avec UpdateManagedRunner.
Une politique par défaut non valide compromet la création. La passerelle valide la politique configurée au démarrage. Si la validation échoue, la passerelle démarre tout de même, mais la création de sandboxes échoue avec l’erreur CWSANDBOX_SERVERLESS_MISCONFIGURED.

Limiter les ressources de calcul

resources fixe les limites de ce qu’un conteneur peut demander et fournit les valeurs appliquées par défaut lorsqu’une Sandbox ne demande rien.

{
  "constraints": {
    "resources": {
      "minCpu": "500m",
      "maxCpu": "8",
      "defaultCpu": "2",
      "minMemory": "1Gi",
      "maxMemory": "32Gi",
      "defaultMemory": "4Gi",
      "maxGpuCount": "2",
      "requireLimits": true
    }
  }
}

Définissez requireLimits sur true pour exiger des limites dans l’allocation résolue de chaque conteneur. Si un conteneur ne déclare pas son allocation de ressources, defaultCpu et defaultMemory fournissent à la fois les demandes de ressources et les limites, à condition que ces deux valeurs par défaut soient supérieures à zéro. Des valeurs par défaut incomplètes ne suffisent pas à satisfaire cette exigence. Ce paramètre n’impose pas que les limites soient égales aux demandes de ressources. Utilisez cpuCeiling et memoryCeiling pour plafonner le total résolu d’une Sandbox, ce qui s’avère utile lorsque la couche de base ajoute ses propres conteneurs. maxGpuCount plafonne le nombre de GPU que chaque conteneur peut demander. Omettez-le pour n’appliquer aucun plafond. Définissez-le sur 0 pour rejeter toute demande de GPU : c’est ainsi que l’on définit un pool sans GPU. Toute demande supérieure au plafond échoue avec l’erreur CWSANDBOX_RESOURCE_CEILING_EXCEEDED. Une valeur de maxGpuCount supérieure au nombre maximum de GPU par Sandbox défini pour votre organisation n’augmente pas ce maximum. Pour plus d’informations, voir Fonctionnement des demandes de GPU.

Restreindre les images

image limite les sources autorisées pour les images de sandbox. Un groupe vide autorise n’importe quelle image. Remplacez [GITHUB-ORG] par le nom de votre organisation ou votre nom d’utilisateur GitHub Container Registry.

{
  "constraints": {
    "image": {
      "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"],
      "allowedImages": ["ghcr.io/[GITHUB-ORG]/agent-base:2024.11"]
    }
  }
}

Restreindre l’accès réseau

Les contraintes réseau fonctionnent comme une enveloppe. Lorsqu’une sandbox déclare du trafic sortant, la politique accepte ou rejette cette déclaration, sans jamais l’élargir. Lorsque la sandbox ne déclare aucun trafic sortant, la politique applique ses valeurs par défaut de trafic sortant, sauf si la sandbox définit deny_egress. Deux paramètres remplissent des rôles distincts :

allowedEgress est la liste d’autorisation du trafic sortant, vérifiée à la création d’une sandbox. Lorsqu’elle n’est pas vide, chaque règle déclarée par la sandbox doit s’y inscrire, et toute règle qui la dépasse est rejetée, et non restreinte. Une liste vide signifie que tout peut être déclaré.
defaultEgress détermine le comportement appliqué en l’absence de demande. Il ne s’applique que lorsque la sandbox ne déclare aucun trafic sortant propre et ne définit pas deny_egress. Toute déclaration le remplace entièrement.

Une règle désigne une seule destination. Utilisez cidr avec d’éventuelles exclusions except, tenant pour une relation avec d’autres bacs à sable, selector pour des charges de travail sélectionnées par libellé, httpsHostname pour un nom d’hôte HTTPS, ou any. Des ports facultatifs permettent de restreindre davantage la règle. Les règles de nom d’hôte n’autorisent que le port TCP 443 et nécessitent un exécuteur qui les prend en charge. Elles ont leur place dans allowedEgress et dans les demandes des sandbox, et non dans defaultEgress.

{
  "constraints": {
    "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" }
      ]
    }
  }
}

L’exemple autorise l’internet public tout en excluant l’espace d’adressage privé et l’adresse des métadonnées d’instance, et permet aux bacs à sable de joindre d’autres bacs à sable de la même organisation. Une sandbox qui ne déclare aucune règle n’a accès qu’aux ressources de la même organisation. Les portées de tenant sont TENANT_SCOPE_SAME_USER et TENANT_SCOPE_SAME_ORG. Une troisième valeur, TENANT_SCOPE_SANDBOX_NETWORK, n’est pas encore prise en charge : toute règle de trafic sortant qui l’utilise est rejetée. L’ingress utilise allowedIngress et defaultIngress pour les ports dont la visibilité est CUSTOM. Une liste d’autorisation non vide s’impose à chaque règle d’ingress déclarée. Lorsqu’une sandbox expose un port CUSTOM sans déclarer de règles d’ingress, defaultIngress s’applique, sauf si la sandbox définit deny_ingress. Les règles d’ingress explicites remplacent cette valeur par défaut. Les règles d’ingress acceptent cidr, tenant ou any ; elles n’acceptent pas de sources fondées sur des noms. Définissez denyHttpsHostnameRules pour rejeter les règles HTTPS fondées sur des noms d’hôte. Cela ne bloque ni les requêtes DNS ni le trafic HTTPS autorisé par des règles CIDR. Définissez dnsEgress sur DNS_EGRESS_MODE_DENY pour bloquer le trafic sortant sur le port UDP/TCP 53. Si ce paramètre est omis, l’accès DNS au résolveur de la plateforme est autorisé. L’accès au DNS et au stockage de la plateforme est accordé indépendamment des règles de destination. Voir Contraintes réseau pour les règles de confinement et le comportement DNS.

Restreindre la posture de sécurité

security régit les privilèges dans l’invité ainsi que le niveau d’isolation dans lequel la sandbox s’exécute.

{
  "constraints": {
    "security": {
      "allowPrivileged": false,
      "allowedCapabilities": ["NET_BIND_SERVICE"],
      "allowedSeccompProfiles": ["RuntimeDefault"],
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu"
    }
  }
}

allowedRuntimeClasses applique un refus par défaut (fail closed). Une liste vide ou absente n’autorise aucun épinglage de classe de runtime concrète : un sandbox ne peut donc épingler une classe que si vous l’ajoutez explicitement à la liste. Définissez defaultCpuRuntimeClass et defaultGpuRuntimeClass pour choisir la classe attribuée à un sandbox lorsqu’il n’en épingle aucune. Vous pouvez également définir runtimeClassMappings pour mapper des classes de runtime portables vers des cibles d’exécution. Une liste de mappages non vide active la sélection via runtime_class_selection et rejette tout épinglage concret via runtime_class. Vous ne pouvez pas combiner les mappages avec allowedRuntimeClasses, defaultCpuRuntimeClass ou defaultGpuRuntimeClass. Pour connaître les champs et les règles de sélection, voir RuntimeClassMapping.

Restreindre les instances, la durée de vie, les métadonnées et les volumes

Les groupes restants sont plus réduits.

Groupe	Champs	Effet
`instance`	`allowedInstanceTypes`	Restreint les types d’instance de nœud sur lesquels une sandbox peut être placée.
`lifecycle`	`defaultLifetimeSeconds`	Durée de vie attribuée à une sandbox qui n’en demande aucune. Le maximum de la plateforme, actuellement fixé à 30 jours, s’applique à toutes les sandboxes ; `maxLifetimeSeconds` a été retiré du document de politique et est désormais rejeté.
`metadata`	`deniedAnnotationPrefixes`, `maxAnnotationCount`	Rejette les clés d’annotation selon leur préfixe et plafonne le nombre d’annotations qu’une sandbox peut définir. `0` signifie aucune limite.
`volumes`	`allowedMedia`, `maxSize`	Restreint les supports de stockage et plafonne la taille de chaque volume. Omettez `STORAGE_MEDIUM_MEMORY` pour interdire les volumes en RAM.

{
  "constraints": {
    "lifecycle": { "defaultLifetimeSeconds": 3600 },
    "volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "100Gi" }
  }
}

La couche de base

Les contraintes délimitent ce qu’une sandbox peut demander. La couche base fournit ce que chaque sandbox reçoit sans avoir à le demander : des valeurs par défaut et des éléments joints tels que l’ordonnanceur, les sélecteurs de nœuds, les tolérances et les secrets d’extraction d’image. Sa forme dépend du runtime de l’exécuteur ; sur un exécuteur Kubernetes, il s’agit d’un fragment de spécification de pod. Tout compte de service autre que celui par défaut est rejeté. Pour connaître les champs autorisés et les restrictions, consultez Fixer les valeurs par défaut de l’administrateur avec la couche de base.

Étapes suivantes

Aperçu des politiques : comment un sandbox est résolu par rapport à une politique, et ce qui a changé par rapport aux profils.
Déployer et gérer un runner : le cycle de vie du runner et ses autres paramètres de configuration.
Aperçu de l’API du plan de contrôle : authentification, masques de champs et contrat des points de terminaison.

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Configurer une politique de Sandbox

Avant de commencer

Lire la politique actuelle

Mettre à jour une politique

Restreindre l’accès à l’API Sandbox par adresse IP source

Modifications de politique et comportement des requêtes

Rétablir l’accès sans restriction de source

Définir une politique par défaut pour les nouveaux exécuteurs

Limiter les ressources de calcul

Restreindre les images

Restreindre l’accès réseau

Restreindre la posture de sécurité

Restreindre les instances, la durée de vie, les métadonnées et les volumes

La couche de base

Étapes suivantes

​Avant de commencer

​Lire la politique actuelle

​Mettre à jour une politique

​Restreindre l’accès à l’API Sandbox par adresse IP source

​Modifications de politique et comportement des requêtes

​Rétablir l’accès sans restriction de source

​Définir une politique par défaut pour les nouveaux exécuteurs

​Limiter les ressources de calcul

​Restreindre les images

​Restreindre l’accès réseau

​Restreindre la posture de sécurité

​Restreindre les instances, la durée de vie, les métadonnées et les volumes

​La couche de base

​Étapes suivantes

Avant de commencer

Lire la politique actuelle

Mettre à jour une politique

Restreindre l’accès à l’API Sandbox par adresse IP source

Modifications de politique et comportement des requêtes

Rétablir l’accès sans restriction de source

Définir une politique par défaut pour les nouveaux exécuteurs

Limiter les ressources de calcul

Restreindre les images

Restreindre l’accès réseau

Restreindre la posture de sécurité

Restreindre les instances, la durée de vie, les métadonnées et les volumes

La couche de base

Étapes suivantes