Docker non-root pour un agent IA : exécuter avec des privilèges minimaux

Un conteneur Docker qui tourne en root simplifie parfois un prototype, mais il augmente l’impact d’une erreur applicative, d’un volume mal monté ou d’un outil d’agent trop puissant. Exécuter un agent IA avec un utilisateur non-root réduit ce privilège par défaut. Cela ne transforme pas le conteneur en sandbox complète : les volumes, le réseau, les capacités, le socket Docker et les secrets restent à contrôler.

Ce tutoriel se concentre sur l’utilisateur à l’intérieur d’une image. Le déploiement global d’un agent Docker, les accès réseau et l’isolation de fichiers demandent des contrôles complémentaires.

Ce que vous allez apprendre

Vous allez identifier les fichiers dont l’agent a besoin, créer un utilisateur dédié dans l’image, lui attribuer uniquement les permissions nécessaires, vérifier son identité à l’exécution et traiter les erreurs de volume sans revenir à root. Les exemples sont génériques afin de ne pas imposer une distribution ou un runtime.

Prérequis

• Une image d’agent qui démarre déjà dans un environnement de test.
• Un petit jeu de fichiers non sensibles pour tester lecture et écriture.
• Un Dockerfile et un fichier d’exclusion de build relus.
• Une destination de sortie limitée pour les résultats de l’agent.
• Une méthode pour reconstruire l’image et revenir à la version précédente.

Ne testez pas la première image non-root avec un volume contenant une production complète. Commencez avec un répertoire de test afin d’identifier les permissions réellement nécessaires.

1. Identifier les droits réellement nécessaires

Listez les opérations du processus : lire du code, écrire un rapport, créer un cache temporaire, ouvrir un port interne ou appeler un service externe. Déterminez les chemins associés. Un agent chargé d’analyser des fichiers n’a pas besoin d’écrire dans le code source ; un agent qui génère un patch peut écrire seulement dans un dossier de sortie à revoir.

Évitez de donner les droits à un répertoire par commodité. Chaque chemin en écriture est une capacité d’impact. Séparez le code en lecture seule, les données temporaires et les résultats. Les données qui doivent rester après l’exécution doivent avoir une politique de sauvegarde et un propriétaire en dehors du conteneur.

Vérification : présentez la liste des chemins à une autre personne. Elle doit pouvoir dire pourquoi chacun est lisible ou inscriptible et quel résultat l’agent y produira.

2. Créer un utilisateur dédié dans l’image

Dans le Dockerfile, créez un utilisateur et un groupe non privilégiés selon les outils de votre image de base. Donnez-leur un identifiant stable lorsque vos volumes hôtes l’exigent. Créez le répertoire de travail et attribuez-en la propriété à cet utilisateur avant de basculer vers l’instruction USER. L’image peut installer ses dépendances pendant le build avec les droits requis, mais le processus final ne doit pas les conserver sans raison.

N’ajoutez pas le nouvel utilisateur à un groupe d’administration pour résoudre un problème de permissions. Si l’application exige un accès privilégié, réexaminez le composant ou la séparation des responsabilités. Un conteneur qui doit modifier l’hôte n’est pas un bon candidat à un agent généraliste.

Vérification : construisez l’image et inspectez le processus lancé. Il doit afficher l’utilisateur prévu et ne pas posséder d’identité root au runtime.

3. Préparer les volumes et répertoires

Les volumes montés depuis l’hôte conservent leurs permissions. Un utilisateur non-root dans le conteneur peut donc être incapable d’écrire dans un dossier créé par root sur l’hôte. Corrigez ce problème par une préparation contrôlée du dossier de sortie, avec un propriétaire et des droits adaptés, plutôt qu’en lançant l’agent en root.

Montez les entrées en lecture seule quand c’est possible. Un fichier source ou un corpus de référence n’a pas besoin d’être modifiable par l’agent. Montez séparément le répertoire de sortie, et n’accordez aucun montage du dossier personnel, de la racine hôte ou du socket Docker par défaut.

Vérification : lancez un test de lecture d’entrée et d’écriture de sortie. Vérifiez ensuite qu’une tentative d’écriture dans l’entrée en lecture seule échoue et que les fichiers de sortie ont le propriétaire attendu.

4. Réduire les privilèges complémentaires

Le non-root ne suffit pas si le conteneur reçoit des capacités Linux inutiles, un mode privilégié, l’accès à des périphériques ou le socket Docker. Examinez les options de lancement et retirez ce qui n’est pas nécessaire. Définissez des limites de mémoire, CPU et nombre de processus adaptées à la charge : elles ne remplacent pas les permissions, mais limitent un agent qui boucle ou crée trop de processus.

Évitez d’ajouter des paquets d’administration au runtime. Les outils de diagnostic peuvent être utiles dans une image de debug séparée, mais ils augmentent la surface de la version exposée. Conservez une image ou un environnement de débogage explicitement distinct plutôt que de donner ces outils à l’agent de production.

Vérification : comparez les options de lancement avec le contrat de l’agent. Tout privilège sans justification doit être retiré ou documenté comme exception temporaire.

5. Tester les refus et la reprise

Un bon test ne vérifie pas seulement que l’agent répond. Vérifiez qu’il ne peut pas écrire dans un chemin interdit, lire un secret hors périmètre, installer un paquet ou modifier l’hôte. Utilisez des fichiers et identifiants de test. La tâche normale doit continuer à réussir avec les permissions réduites ; sinon, cherchez le chemin précis manquant au lieu de rétablir des droits globaux.

Préparez aussi le retour à l’image antérieure. Épinglez les versions, conservez le résultat des tests et documentez la commande de déploiement approuvée. Si la migration de permissions casse un workflow légitime, vous devez pouvoir revenir temporairement tout en enquêtant sur le droit réellement requis.

Vérification : exécutez un test positif et au moins deux tests négatifs. Conservez le résultat, la version de l’image et les fichiers produits dans le rapport de livraison.

Problèmes fréquents et solutions

L’application ne peut plus écrire son cache. Créez un répertoire de cache détenu par l’utilisateur non-root ou rendez le cache temporaire. Ne rendez pas tout le système inscriptible.

Le volume hôte refuse l’écriture. Ajustez le propriétaire et les droits du seul répertoire de sortie, puis retestez. Évitez de résoudre l’erreur par un conteneur root.

Une dépendance veut installer un paquet au démarrage. Déplacez l’installation dans la phase de build et épinglez la dépendance. Le runtime ne doit pas modifier son environnement par défaut.

L’agent a besoin d’un outil système. Évaluez un outil étroit ou un service séparé plutôt que d’ajouter un accès privilégié au conteneur.

FAQ

Le non-root protège-t-il contre toute fuite de données ?

Non. Il réduit les privilèges du processus, mais les volumes, secrets, réseau et outils disponibles restent déterminants.

Peut-on être root au build et non-root au runtime ?

Oui, c’est un schéma courant : les opérations de construction peuvent nécessiter certains droits, tandis que le processus final est exécuté avec un utilisateur dédié.

Faut-il modifier les permissions de tout le projet ?

Non. Limitez les changements au répertoire de travail et de sortie nécessaires, puis vérifiez leur effet.

Pourquoi le socket Docker est-il risqué ?

Il peut offrir une capacité de contrôle très large sur l’hôte. Un agent non fiable ne devrait pas le recevoir par défaut.

Comment vérifier l’utilisateur réel ?

Inspectez le processus dans le conteneur et ajoutez un contrôle automatisé qui confirme l’identité attendue au lancement de l’image.

Conclusion

Docker non-root pour un agent IA est une amélioration concrète lorsqu’elle s’accompagne de volumes étroits, de secrets limités et de tests de refus. L’objectif n’est pas de forcer une configuration qui casse l’agent, mais de retirer les privilèges qui ne servent pas à sa tâche et de prouver que le workflow reste fonctionnel.

Sources et limites

Sources primaires : Docker — non-root containers, Dockerfile reference et OWASP Docker Security Cheat Sheet. Les commandes de création d’utilisateur dépendent de l’image de base. Ce guide ne remplace pas une sandbox, une revue de volumes ou une analyse de menace.