Alors que les applications d'IA passent du stade de simples modèles linguistiques répondant à des questions à celui d'« agents » capables d'exécuter des tâches réelles telles que lancer des commandes, installer des paquets et lire des fichiers, un nouveau défi de sécurité a émergé. Ces agents, qui fonctionnent souvent sur la base de données récupérées sur Internet, sont considérés comme du « code non fiable » (Untrusted Code) ayant accès à des données sensibles, ce qui rend leur exécution dans des environnements de production très risquée s'ils ne sont pas isolés avec précision.
Qu'est-ce que le projet OpenShell ?
OpenShell, un projet Sandbox de la CNCF initié par NVIDIA, est une solution visant à fournir un environnement d'exécution isolé (Runtime) pour ces agents. Le projet repose sur l'idée d'un « superviseur » (Supervisor) fiable fonctionnant en dehors de l'environnement d'isolation, qui prend des décisions sur ce à quoi l'agent peut accéder en fonction de politiques prédéfinies via des fichiers YAML. OpenShell offre quatre niveaux fondamentaux de contrôle :
- Système de fichiers (Filesystem) : En utilisant la technologie Landlock, les chemins auxquels l'agent peut accéder en lecture ou en écriture sont définis, empêchant ainsi l'accès aux fichiers système sensibles.
- Processus (Process) : L'agent est exécuté en tant qu'utilisateur non privilégié (Non-root) avec l'application du protocole seccomp pour restreindre les appels système.
- Réseau (Network) : Le trafic sortant est bloqué par défaut, avec la possibilité de l'autoriser sur la base de règles précises incluant le nom de l'exécutable, l'hôte, le port et même la méthode de requête HTTP.
- Données sensibles (Credentials) : L'agent ne voit pas les clés API réelles, mais des « espaces réservés » (Placeholders), le superviseur ne les remplaçant par les clés réelles qu'en cas de besoin et pour les entités autorisées.
Intégration avec Kubernetes et capacités avancées
Contrairement aux solutions qui tentent de contourner l'architecture Kubernetes, OpenShell s'appuie sur le projet Agent Sandbox du SIG Apps. Les agents apparaissent dans le système comme des objets Kubernetes familiers tels que des Pods, des Services et des Secrets. L'avantage essentiel ici est la capacité d'OpenShell à fournir une visibilité au niveau de la couche 7 (L7) ; alors que les politiques réseau traditionnelles (NetworkPolicy) peuvent autoriser un Pod à accéder à un site spécifique, OpenShell peut déterminer si une commande curl est autorisée à lire des données depuis GitHub mais interdite de créer (POST) de nouveaux problèmes (Issues).
Comparaison technique : OpenShell vs Agent Substrate
Un autre projet de la CNCF se distingue dans ce domaine : Agent Substrate. La différence fondamentale entre les deux réside dans la philosophie de conception :
- OpenShell : Se concentre sur la sécurité et le contrôle granulaire. C'est le choix optimal pour les agents qui ont besoin d'accéder aux systèmes de production et qui nécessitent des politiques strictes pour chaque requête (Per-request policy).
- Agent Substrate : Se concentre sur le passage à l'échelle et la réduction des coûts. Il repose sur la suspension (Suspending) des agents inactifs au lieu d'allouer un Pod complet à chaque agent, ce qui le rend adapté aux modèles nécessitant une haute densité et un faible coût.
Les prévisions techniques suggèrent la possibilité d'intégrer les deux projets à l'avenir, de sorte qu'OpenShell fournisse les politiques de contrôle, tandis que Substrate assure l'efficacité de l'isolation et du passage à l'échelle.
Pourquoi cette évolution est-elle importante pour les ingénieurs de plateforme ?
OpenShell représente un pont nécessaire entre la flexibilité de l'IA et la rigueur de la sécurité du cloud computing. Pour les administrateurs Kubernetes, il ne suffit plus d'isoler les conteneurs (Containers) traditionnels ; il est devenu nécessaire de contrôler le comportement de « l'agent intelligent » à l'intérieur du conteneur. Grâce à l'intégration avec des outils comme Kyverno, les ingénieurs peuvent imposer des politiques d'admission (Admission Control) garantissant que les agents ne fonctionnent qu'avec des images spécifiques et fiables, tout en fixant des limites aux ressources de traitement et de mémoire, garantissant ainsi qu'un agent d'IA ne devienne pas une source de menace de sécurité ou une consommation excessive des ressources du cluster.