Pourquoi les agents d'IA ont-ils besoin d'environnements d'exécution isolés ?
Les activités des agents d'IA ne se limitent pas à l'appel d'API cloud ; elles s'étendent à l'exécution de commandes shell, à l'installation de paquets, à la lecture de fichiers et à l'ouverture de connexions réseau directes. Dans de nombreux cas, l'agent agit sur la base de scripts non fiables récupérés sur Internet quelques instants auparavant, ce qui en fait un code non sécurisé détenant des identifiants réels au sein de l'infrastructure.
Le projet OpenShell, initié par NVIDIA et ayant rejoint les projets Sandbox de la CNCF, fournit un environnement d'exécution sécurisé pour les agents en isolant chaque agent dans un conteneur dédié. Le système repose sur un superviseur de confiance (Supervisor) situé en dehors de l'environnement isolé pour contrôler les autorisations selon quatre axes fondamentaux définis par les fichiers YAML :
- Système de fichiers : Restriction des chemins en lecture et écriture en utilisant la technologie Landlock du noyau Linux, de sorte que des répertoires comme /usr et /etc soient en lecture seule.
- Gestion des processus : Suppression des privilèges root du conteneur, annulation de toutes les capacités du noyau et application des règles seccomp avant le démarrage.
- Contrôle réseau : Blocage du trafic sortant par défaut, tout en autorisant des domaines spécifiques selon le nom du fichier exécutable, l'hôte, le protocole et le port.
- Identifiants : Dissimulation des clés réelles à l'agent et remplacement par des jetons temporaires gérés uniquement par le superviseur lors de la connexion aux points de terminaison autorisés.
Comment fonctionne l'environnement isolé dans Kubernetes
Au niveau de Kubernetes, OpenShell ne contient pas de planificateur spécifique, mais tire parti du projet Agent Sandbox du groupe d'intérêt spécial SIG Apps. La passerelle OpenShell Gateway gère le cycle de vie de l'environnement, tandis qu'Agent Sandbox traduit ces demandes en ressources Kubernetes standard telles que les Pods, Services, PVC et NetworkPolicies.
Le cycle commence par l'envoi d'une demande de création d'environnement isolé via le protocole mTLS à la Gateway, où l'identité de l'appelant est vérifiée, les politiques traduites et toute configuration non sécurisée annulée. Ensuite, des politiques réseau sont créées pour bloquer le trafic externe de l'agent et limiter la communication interne au seul superviseur via le port 5500. À l'étape suivante, le superviseur doit vérifier les propriétés de sécurité du Pod créé, comme s'assurer qu'aucun privilège root n'est utilisé ou qu'aucun espace de noms hôte n'est partagé, avant de lever les restrictions de planification et de démarrer l'agent d'IA.
Comparaison entre OpenShell et Agent Substrate
Un autre projet au sein de la CNCF propose une solution similaire : Agent Substrate. Bien que les deux projets visent à isoler les agents d'IA sur Kubernetes, ils diffèrent fondamentalement dans leur infrastructure et leurs cas d'utilisation :
- Granularité des politiques : OpenShell inspecte chaque requête réseau au niveau du superviseur dédié à un environnement unique, permettant par exemple de lire des tickets GitHub tout en empêchant la création de nouveaux tickets avec le même outil. Substrate, quant à lui, analyse le trafic au niveau d'une passerelle de sortie commune (Egress Gateway) en fonction du domaine et de l'hôte.
- Visibilité dans Kubernetes : Chaque environnement isolé dans OpenShell est considéré comme un ensemble de ressources pouvant être visualisées et gérées via les outils Kubernetes natifs et le RBAC. En revanche, Substrate conserve les modèles et les politiques dans sa propre base de données PostgreSQL, en dehors du serveur API de Kubernetes.
- Modèle d'isolation et évolutivité : Substrate nécessite des technologies d'isolation strictes comme gVisor ou Cloud Hypervisor pour permettre l'arrêt et la reprise des conteneurs inactifs afin de réduire les coûts, tandis qu'OpenShell propose des conteneurs Linux standard avec la possibilité d'intégrer des technologies d'isolation plus strictes si nécessaire.
Renforcer la sécurité avec le moteur Kyverno
Alors qu'OpenShell contrôle le comportement interne de l'agent, des moteurs de politique comme Kyverno interviennent pour garantir que les ressources Kubernetes elles-mêmes ne sont pas manipulées lors de l'admission (Admission Control). Kyverno garantit la vérification de l'installation des versions d'images (Image Digests), définit les limites maximales d'utilisation du processeur et de la mémoire, et empêche l'octroi de privilèges étendus aux rôles RBAC des superviseurs.
De plus, les outils de surveillance du noyau basés sur eBPF, tels que Runtime for Kyverno, permettent de détecter les outils d'IA non autorisés au sein des clusters, comme l'exécution de clients CLI ou la connexion à des modèles externes sans passer par les passerelles de sécurité approuvées.
Qu'est-ce qui change concrètement pour les ingénieurs plateforme ?
L'imposition de la sécurité sur les applications d'IA ne se limite plus à la sécurisation des API, mais s'étend au contexte d'exécution réel du code à l'intérieur des conteneurs. Le projet OpenShell donne aux équipes plateforme la capacité de contrôler finement le niveau 7 (L7) pour chaque opération exécutée par l'agent, tandis que l'intégration avec Kyverno garantit le maintien des normes de gouvernance et de conformité structurelle au sein des environnements Kubernetes sans complexité opérationnelle supplémentaire.