Déployer un agent IA avec Docker : isolation, secrets et contrôles

Docker peut rendre le déploiement d’un agent IA plus reproductible, mais il ne rend pas l’agent sûr par défaut. Un conteneur qui reçoit le socket Docker, le répertoire entier d’un projet ou des secrets d’administration dispose encore d’une surface d’action trop large. La bonne approche consiste à définir ce que l’agent doit faire, à ne monter que les données nécessaires, à exécuter avec un utilisateur non privilégié et à tester les refus aussi sérieusement que les succès.

Ce tutoriel décrit une base défensive pour un agent qui appelle un modèle distant ou traite des tâches limitées. Il ne faut pas l’appliquer telle quelle à une production sans adapter les permissions, les données et le modèle de menace.

Ce que vous allez apprendre

Vous allez créer une image reproductible, lancer un agent avec peu de privilèges, injecter ses secrets sans les mettre dans le dépôt, limiter les volumes et vérifier ses journaux. Vous apprendrez aussi pourquoi le conteneur ne suffit pas lorsque l’agent peut exécuter des outils, télécharger des fichiers ou appeler des systèmes tiers.

Prérequis

• Docker Engine installé depuis la documentation officielle.
• Un petit service d’agent dont les dépendances sont connues.
• Un compte de test et des clés non productives pour les premiers essais.
• Un répertoire de travail contenant uniquement les fichiers nécessaires au test.
• Une procédure pour supprimer ou révoquer une clé de test après l’exercice.

Ne transmettez pas de clé d’administration, de fichier .env complet ou de socket Docker à un conteneur de test. Ces raccourcis transforment l’isolation apparente en accès à l’hôte.

1. Définir le contrat d’exécution

Avant le Dockerfile, écrivez une phrase précise : « l’agent lit tels fichiers, appelle tels domaines et produit tel répertoire ». Ajoutez les actions interdites : pas d’accès à l’hôte, pas de modification de la configuration, pas de secret de production et pas de réseau arbitraire. Cette liste sert à choisir les volumes, variables et règles réseau.

Vérification : un collègue doit pouvoir lire la liste et dire quels fichiers, secrets et destinations sont nécessaires. Si vous ne pouvez pas l’écrire, le conteneur est encore trop générique pour être évalué.

2. Construire une image minimale

Utilisez une image de base maintenue et une version de runtime explicite. Copiez d’abord les manifestes de dépendances, installez les dépendances nécessaires, puis copiez le code utile. Ajoutez un fichier .dockerignore afin d’exclure les caches, les journaux, les clés, les fichiers d’environnement et les répertoires non requis. Une image plus petite ne garantit pas la sécurité, mais elle réduit le nombre de fichiers disponibles par erreur.

Créez un utilisateur non-root dans l’image, attribuez-lui uniquement le répertoire de travail et exécutez le processus avec cet utilisateur. Évitez d’installer des outils d’administration qui ne servent pas au runtime. Les instructions exactes varient selon le langage ; la propriété importante est que l’application ne soit pas le superutilisateur.

Vérification : inspectez la liste des fichiers envoyés au build et démarrez le conteneur. À l’intérieur, contrôlez l’utilisateur effectif et vérifiez qu’il ne peut pas écrire dans des emplacements système non prévus.

3. Injecter les secrets sans les copier

Une clé API ne doit pas apparaître dans le Dockerfile, l’image, l’historique Git ou le journal d’un job. Fournissez-la au moment de l’exécution via le mécanisme retenu par votre orchestrateur ou un gestionnaire de secrets. Donnez à l’agent une clé dédiée, limitée au service et à l’environnement de test. Prévoyez sa date de rotation et la manière de vérifier qu’elle est révoquée.

Évitez aussi de passer un fichier contenant toutes les variables d’une application au conteneur. L’agent n’a besoin que de ses paramètres. Une séparation par tâche rend l’incident plus contenable et la revue plus simple.

Vérification : recherchez le secret dans le contexte de build, l’historique de l’image et les journaux de démarrage. Testez ensuite l’échec attendu avec une clé désactivée ; le message doit rester utile sans révéler la valeur.

4. Limiter fichiers et ressources

Montez un répertoire de travail dédié plutôt que le dossier personnel ou la racine d’un dépôt. Montez-le en lecture seule si l’agent n’a qu’à analyser des fichiers. Si une écriture est nécessaire, utilisez un répertoire de sortie séparé, avec une revue avant intégration. N’accordez jamais le socket Docker par défaut : il donne souvent une capacité de contrôle de l’hôte incompatible avec un agent non fiable.

Fixez aussi des limites de mémoire, CPU et temps adaptées au cas d’usage. Elles n’empêchent pas toutes les attaques, mais limitent un workflow qui boucle ou télécharge trop de données. Ajoutez un quota de taille pour les fichiers acceptés par l’agent et un timeout pour les appels externes.

Vérification : essayez de lire un fichier hors volume et d’écrire dans le volume en lecture seule : ces actions doivent échouer. Exécutez ensuite une tâche normale et vérifiez qu’elle ne dépasse pas les limites choisies.

5. Contrôler réseau et outils

Un agent qui peut lire une instruction dans un document puis appeler n’importe quel domaine peut être conduit à exfiltrer une donnée. Autorisez seulement les destinations nécessaires quand votre environnement le permet, utilisez des délais courts et journalisez les échecs de façon redactionnée. Si l’agent appelle des outils locaux, exposez une interface étroite : une fonction de lecture ciblée est plus facile à contrôler qu’un shell complet.

Traitez tout contenu entrant comme des données. Une page, un fichier ou une réponse d’outil peut contenir une instruction hostile ; elle ne doit jamais élargir les permissions définies dans votre contrat d’exécution.

Vérification : utilisez une entrée de test qui demande explicitement une action interdite. Le processus doit refuser ou signaler la demande, sans modifier de fichier ni envoyer de requête vers une destination non autorisée.

6. Journaliser et préparer la reprise

Conservez des événements utiles : identifiant de tâche, durée, version d’image, résultat et erreur classée. Retirez tokens, prompts sensibles, pièces jointes complètes et réponses contenant des données personnelles. Associez les journaux à une rétention limitée et à des droits d’accès cohérents avec leur sensibilité.

Documentez aussi le rollback : image précédente, configuration connue, procédure de révocation et nettoyage des données temporaires. Un déploiement n’est pas terminé lorsque le conteneur démarre, mais lorsqu’il peut être arrêté et remplacé sans perdre le contrôle des données.

Problèmes fréquents et solutions

Le conteneur fonctionne seulement en root. Corrigez les propriétaires de fichiers et le répertoire de travail ; ne résolvez pas le problème en ajoutant des privilèges généraux.

Le build contient des secrets. Stoppez la publication de l’image, révoquez la clé et retirez-la du contexte de build. Une clé committée ou intégrée à une couche doit être considérée exposée.

L’agent ne peut pas écrire son résultat. Ajoutez un volume de sortie spécifique et contrôlez les fichiers produits, plutôt que d’ouvrir l’ensemble du projet.

Un outil exige un accès hôte. Réexaminez le besoin. Un runner séparé, une API limitée ou une tâche manuelle peut être plus sûr qu’un montage privilégié.

FAQ

Docker isole-t-il complètement un agent IA ?

Non. L’isolation dépend aussi des volumes, du réseau, des capacités Linux, des secrets et de l’hôte. Docker est une couche utile, pas une frontière unique.

Faut-il toujours désactiver le réseau ?

Pas si l’agent doit appeler une API. Réduisez plutôt les destinations et les permissions au besoin réel, puis mesurez les appels.

Pourquoi éviter le socket Docker ?

Il peut donner au conteneur un contrôle très large sur l’hôte. Ne l’utilisez que dans une architecture explicitement revue pour cela.

Comment mettre à jour l’image ?

Épinglez les versions, reconstruisez, scannez selon votre politique, testez dans un environnement isolé et gardez une image précédente pour le rollback.

Quelle est la première vérification à automatiser ?

Commencez par détecter les secrets dans le contexte de build et par un test négatif de permissions sur les volumes et le réseau.

Conclusion

Déployer un agent IA avec Docker devient plus robuste quand l’image, les secrets, les fichiers et le réseau sont chacun limités et testés. Le principe central est simple : l’agent doit pouvoir faire son travail, mais pas davantage. Mesurez le comportement réel et conservez une procédure de révocation plutôt que de faire confiance au seul mot « conteneur ».

Sources et limites

Sources primaires : Docker security, Docker build secrets, OWASP LLM Top 10 et OWASP Docker Security Cheat Sheet. Les options exactes dépendent de l’hôte et de l’orchestrateur. Ce guide ne remplace pas une revue de menace ou un test d’isolation de votre infrastructure.