doc-locale/fr-fr/user/duo_agent_platform/environment_sandbox.md
{{< history >}}
ai_duo_agent_platform_network_firewall et ai_dap_executor_connects_over_wsai_duo_agent_platform_network_firewall a été activé dans GitLab 18.7.ai_dap_executor_connects_over_ws a été activé dans GitLab 18.7.network_policy a été introduit dans GitLab 18.10.allow_all_unix_sockets a été introduit dans GitLab 18.11.dap_instance_network_access_controls et dap_group_network_access_controls. Désactivé par défaut.dap_instance_network_access_controls et dap_group_network_access_controls ont été activés dans GitLab 19.0.{{< /history >}}
Le sandbox de l'environnement d'exécution fournit une isolation réseau et système de fichiers au niveau applicatif qui contribue à protéger les flows distants de GitLab Duo Agent Platform contre les accès réseau non autorisés et l'exfiltration de données. Il est conçu pour aider à prévenir les tentatives d'exfiltration de données, le chargement de code malveillant depuis des sources externes et la collecte de données non autorisée, tout en maintenant la connectivité nécessaire aux opérations légitimes des flows.
Le sandbox de l'environnement d'exécution est automatiquement appliqué lors de l'utilisation d'une image Docker compatible avec Anthropic Sandbox Runtime (SRT) installé. Cela inclut l'utilisation de l'image Docker GitLab par défaut (release v0.0.6 et versions ultérieures) ou d'une image personnalisée avec SRT installé.
Le sandbox est activé lorsque :
Pour obtenir des informations sur les différences de variables CI/CD entre les configurations d'images par défaut et personnalisées, consultez Variables d'exécution des flows.
Pour utiliser le sandbox de l'environnement d'exécution, vous avez besoin de :
v0.0.6 ou supérieure, ou d'une image personnalisée avec Anthropic Sandbox Runtime (SRT) installé.Le sandbox de l'environnement d'exécution utilise Anthropic Sandbox Runtime (SRT) pour encapsuler l'exécution des flows avec les protections suivantes :
Si vous utilisez une image personnalisée, par exemple avec un agent-config.yml, Anthropic SRT version 0.0.20 ou ultérieure doit être installé et disponible dans l'environnement.
SRT est disponible via npm sous la forme @anthropic-ai/sandbox-runtime. L'exemple suivant montre l'étape d'installation dans un Dockerfile :
# Install srt sandboxing with cache clearing and verification
ARG SANDBOX_RUNTIME_VERSION=0.0.20
RUN npm cache clean --force && \
npm install -g @anthropic-ai/sandbox-runtime@${SANDBOX_RUNTIME_VERSION} && \
test -s "$(npm root -g)/@anthropic-ai/sandbox-runtime/package.json" && \
srt --version
Au moment de l'exécution, le runner vérifie que SRT est disponible et fonctionnel :
$ if which srt > /dev/null; then
$ echo "SRT found, creating config..."
SRT found, creating config...
$ echo '{"network":{"allowedDomains":["host.docker.internal","localhost","gitlab.com","*.gitlab.com","duo-workflow-svc.runway.gitlab.net"],"deniedDomains":[],"allowAllUnixSockets":false},"filesystem":{"denyRead":["~/.ssh"],"allowWrite":["./","/tmp"],"denyWrite":["/opt/.gitlab-sandbox"],"allowGitConfig":true}}' > /opt/.gitlab-sandbox/srt-settings.json
$ echo "Testing SRT sandbox capabilities..."
Testing SRT sandbox capabilities...
L'erreur suivante peut se produire au moment de l'exécution, ce qui peut indiquer que les dépendances de SRT ne sont pas disponibles :
Warning: SRT found but can't create sandbox (insufficient privileges), running command directly
Pour résoudre ce problème :
Utilisez bash pour vérifier l'image avec la commande suivante :
docker run --rm -it <image>:<tag> /bin/bash
Utilisez srt :
srt ls
Si l'erreur suivante s'affiche, vous devez installer des dépendances supplémentaires dans votre image personnalisée :
Error: Sandbox dependencies are not available on this system. Required: ripgrep (rg), bubblewrap (bwrap), and socat.
Lorsque le sandbox de l'environnement d'exécution est appliqué, les restrictions suivantes sont appliquées.
Utilisez un fichier agent-config.yml pour configurer certains de vos paramètres de sandbox.
Par défaut, le sandbox autorise l'accès aux configurations suivantes :
Seules les variables d'environnement et les paramètres requis pour exécuter les opérations DAP et Git sont accessibles depuis l'environnement sandbox.
Le sandbox applique les restrictions suivantes au système de fichiers :
~/.ssh) sont bloquées../) et /tmp./opt/.gitlab-sandbox (utilisé pour les fichiers internes à la plateforme, comme les paramètres du sandbox).SRT est inclus dans l'image Docker fournie par défaut par GitLab. Vous pouvez également installer SRT sur une image personnalisée.
Lorsque SRT est installé, les flows ne peuvent accéder par défaut qu'aux domaines suivants. Ces domaines sont toujours autorisés et ne peuvent pas être supprimés :
localhosthost.docker.internalgitlab.com, *.gitlab.com)Si vous utilisez une image personnalisée sans SRT, aucune restriction réseau n'est appliquée et le flow peut accéder à n'importe quel domaine accessible depuis le runner.
[!note] La
network_policyn'autorise pas"*"dansallowed_domainsni dansdenied_domains. SRT ne prend pas en charge l'activation de tout le trafic réseau. Cependant, les caractères génériques sont autorisés dans les domaines, par exemple"*.domain.com".
Lorsqu'un propriétaire de groupe principal sur GitLab.com ou un administrateur d'instance sur GitLab Self-Managed configure les contrôles d'accès réseau, ces paramètres définissent la politique de référence pour tous les flows. La case à cocher Allow projects to extend network sandbox settings détermine quels paramètres sont appliqués lorsque les propriétaires de projets les configurent dans agent-config.yml.
Flexible mode (Allow projects to extend network sandbox settings activé) :
allowed_domains de agent-config.yml sont fusionnés avec la liste d'autorisation de l'administrateur.denied_domains de agent-config.yml sont fusionnés avec la liste de refus de l'administrateur.include_recommended_allowed dans agent-config.yml remplace le paramètre de l'administrateur.allow_all_unix_sockets dans agent-config.yml remplace le paramètre de l'administrateur.Strict mode (Allow projects to extend network sandbox settings désactivé) :
denied_domains de agent-config.yml sont fusionnés avec la liste de refus de l'administrateur.include_recommended_allowed ne peut être défini qu'à false pour renforcer un paramètre activé par l'administrateur. Cela n'a aucun effet lorsque l'administrateur l'a désactivé.allow_all_unix_sockets ne peut être défini qu'à false pour renforcer un paramètre activé par l'administrateur. Cela n'a aucun effet lorsque l'administrateur l'a désactivé.allowed_domains de agent-config.yml sont ignorés.Pour autoriser ou refuser des domaines supplémentaires, ajoutez une network_policy à votre fichier agent-config.yml :
network_policy:
include_recommended_allowed: true # default: false
allow_all_unix_sockets: true # default: false
allowed_domains:
- my-own-site.com
denied_domains:
- malicious.com
Utilisez le paramètre allow_all_unix_sockets pour accorder au flow l'accès à tous les sockets de domaine Unix sur l'hôte. Cette option est désactivée par défaut.
[!warning] L'activation de
allow_all_unix_socketsaccorde l'accès à tous les sockets Unix. N'activez cette option que si nécessaire et uniquement dans des environnements de confiance.
{{< history >}}
dap_instance_network_access_controls et dap_group_network_access_controls. Désactivé par défaut.{{< /history >}}
[!flag] La disponibilité de cette fonctionnalité est contrôlée par un feature flag. Pour plus d'informations, consultez l'historique. Cette fonctionnalité est disponible à des fins de test, mais n'est pas prête pour une utilisation en production.
En plus des paramètres agent-config.yml au niveau du projet, les administrateurs et les propriétaires de groupe principal peuvent gérer les contrôles d'accès réseau via l'interface utilisateur GitLab. Ces paramètres sont stockés au niveau de l'instance (GitLab Self-Managed) ou au niveau du groupe principal (GitLab.com) et sont hérités par tous les projets sous-jacents.
Pour une description de la façon dont ces paramètres se combinent avec le agent-config.yml au niveau du projet, consultez Contrôles de la politique réseau par l'administrateur.
Prérequis :
Pour configurer les contrôles d'accès réseau au niveau de l'instance :
agent-config.yml, ajouter d'autres domaines et autoriser tous les sockets Unix.Prérequis :
Pour configurer les contrôles d'accès réseau au niveau du groupe :
duoSettingsUpdate.ai_settings_attributes.aiDomainSettingsInstanceUpdate et aiDomainSettingsNamespaceUpdate.Pour donner à vos flows l'accès à un ensemble de domaines externes utilisés pour les registres de paquets et les outils de développement, activez le paramètre include_recommended_allowed.
Ce paramètre est désactivé par défaut (false). Pour l'activer, dans votre fichier agent-config.yml, définissez include_recommended_allowed sur true.
Lorsque les contrôles d'accès réseau sont activés en mode strict (Allow projects to extend network sandbox settings désactivé), vous pouvez uniquement désactiver include_recommended_allowed. Le définir sur true n'a aucun effet lorsque l'administrateur l'a désactivé.
[!warning] L'activation de
include_recommended_allowedautorise l'accès réseau à un large ensemble de domaines externes. Ces points de sortie pourraient potentiellement être utilisés pour exfiltrer des données de votre environnement. N'activez cette option que si nécessaire et uniquement dans des environnements de confiance.
Ce paramètre active l'accès aux domaines suivants :
github.comwww.github.comapi.github.comnpm.pkg.github.comraw.githubusercontent.compkg-npm.githubusercontent.comobjects.githubusercontent.comcodeload.github.comavatars.githubusercontent.comcamo.githubusercontent.comgist.github.comgitlab.comwww.gitlab.comregistry.gitlab.combitbucket.orgwww.bitbucket.orgapi.bitbucket.orgregistry-1.docker.ioauth.docker.ioindex.docker.iohub.docker.comwww.docker.comproduction.cloudflare.docker.comdownload.docker.comgcr.io*.gcr.ioghcr.iomcr.microsoft.com*.data.mcr.microsoft.compublic.ecr.awscloud.google.comaccounts.google.comgcloud.google.comstorage.googleapis.comcompute.googleapis.comcontainer.googleapis.comartifactregistry.googleapis.comcloudresourcemanager.googleapis.comoauth2.googleapis.comwww.googleapis.comlogin.microsoftonline.compackages.microsoft.comdotnet.microsoft.comdot.netdev.azure.coms3.amazonaws.com*.s3.amazonaws.com*.codeartifact.amazonaws.com*.s3.api.aws*.codeartifact.api.awsdownload.oracle.comyum.oracle.comregistry.npmjs.orgwww.npmjs.comwww.npmjs.orgnpmjs.comnpmjs.orgyarnpkg.comregistry.yarnpkg.compypi.orgwww.pypi.orgfiles.pythonhosted.orgpythonhosted.orgtest.pypi.orgpypi.python.orgpypa.iowww.pypa.iorubygems.orgwww.rubygems.orgapi.rubygems.orgindex.rubygems.orgruby-lang.orgwww.ruby-lang.orgrubyonrails.orgwww.rubyonrails.orgrvm.ioget.rvm.iocrates.iowww.crates.ioindex.crates.iostatic.crates.iorustup.rsstatic.rust-lang.orgwww.rust-lang.orgproxy.golang.orgsum.golang.orgindex.golang.orggolang.orgwww.golang.orggoproxy.iopkg.go.devmaven.orgrepo.maven.orgcentral.maven.orgrepo1.maven.orgjcenter.bintray.comgradle.orgwww.gradle.orgservices.gradle.orgplugins.gradle.orgkotlin.orgwww.kotlin.orgspring.iorepo.spring.iopackagist.orgwww.packagist.orgrepo.packagist.orgnuget.orgwww.nuget.orgapi.nuget.orgpub.devapi.pub.devhex.pmwww.hex.pmcpan.orgwww.cpan.orgmetacpan.orgwww.metacpan.orgapi.metacpan.orgcocoapods.orgwww.cocoapods.orgcdn.cocoapods.orghaskell.orgwww.haskell.orghackage.haskell.orgswift.orgwww.swift.orgarchive.ubuntu.comsecurity.ubuntu.comubuntu.comwww.ubuntu.com*.ubuntu.comppa.launchpad.netlaunchpad.netwww.launchpad.netdl.k8s.iopkgs.k8s.iok8s.iowww.k8s.ioreleases.hashicorp.comapt.releases.hashicorp.comrpm.releases.hashicorp.comarchive.releases.hashicorp.comhashicorp.comwww.hashicorp.comrepo.anaconda.comconda.anaconda.organaconda.orgwww.anaconda.comanaconda.comcontinuum.ioapache.orgwww.apache.orgarchive.apache.orgdownloads.apache.orgeclipse.orgwww.eclipse.orgdownload.eclipse.orgnodejs.orgwww.nodejs.orgsourceforge.net*.sourceforge.netpackagecloud.io*.packagecloud.iojson-schema.orgwww.json-schema.orgjson.schemastore.orgwww.schemastore.org*.modelcontextprotocol.ioSi le sandbox est indisponible ou ne peut pas être appliqué :
Cela garantit que les flows continuent de s'exécuter même si le sandbox ne peut pas être activé, tout en vous alertant de la situation.