Docker LLM sécurité : comprendre le périmètre de confiance

Docker repose sur une architecture client-serveur : un client dialogue avec le daemon, qui construit les images, lance les conteneurs et récupère les images depuis un registre public ou privé. La fiche technique de l'ANSSI sur le déploiement de conteneurs Docker rappelle la différence essentielle : contrairement à une machine virtuelle, le conteneur fonctionne directement dans le noyau de la machine hôte. Il isole un processus ; il ne garantit pas un confinement absolu.

Ce que contient un LLM conteneurisé

Un déploiement réaliste assemble un serveur d'inférence (Ollama, vLLM ou llama.cpp), les poids et le tokenizer, une API, une interface comme OpenWebUI, une base vectorielle pour le RAG (retrieval-augmented generation, génération augmentée par récupération), des connecteurs vers la GED ou la messagerie, et un accès GPU. Chacun de ces composants est une surface d'attaque distincte.

Actifs et adversaires

Actifs à protéger Adversaires plausibles
Poids, prompts, corpus RAG Attaquant externe via l'API exposée
Secrets, clés d'API, configurations Utilisateur interne malveillant ou curieux
Journaux et sauvegardes Image ou modèle compromis en amont
Disponibilité du service Dépendance vulnérable, administrateur trop privilégié

Le modèle de menace spécifique

Les scénarios à couvrir sont l'évasion du conteneur, l'accès abusif au socket Docker, les montages de volumes excessifs, l'exposition réseau directe du serveur d'inférence, l'exfiltration par les prompts ou les sorties, la prompt injection indirecte via des documents RAG et le déni de service par saturation CPU, mémoire ou VRAM.

La fiche CNIL sur la sécurité du développement d'un système d'IA apporte une nuance décisive : les risques les plus vraisemblables portent aujourd'hui sur les autres composants, comme les sauvegardes, les interfaces et les communications, plutôt que sur le modèle lui-même. Les recommandations de l'ANSSI pour un système d'IA générative (29 avril 2024) appellent à une posture de prudence de la conception à la production. Ma thèse est simple : la sécurité se construit en profondeur, de la provenance de l'image jusqu'à la réponse à incident.

Durcir l'image, le modèle et la chaîne d'approvisionnement

La sécurité commence avant le premier docker run. Une image volumineuse embarque des centaines de paquets dont personne ne suit les vulnérabilités.

Une image minimale et reproductible

Je recommande une image de base maintenue, un build multi-stage qui laisse compilateurs et outils de développement dans l'étape de construction, aucun shell inutile en production et des dépendances verrouillées avec leurs versions. Le tag latest est à proscrire : il désigne une cible mouvante. Référencez des versions immuables ou, mieux, des digests sha256, stockez les images dans un registre privé et signez ou attestez les artefacts produits. Un scan de vulnérabilités des images et bibliothèques à chaque build, complété d'une analyse des composants open source, permet de prioriser les correctifs selon l'exposition réelle du service.

Les poids du modèle sont un artefact à part

Un fichier de poids n'est pas inerte. La CNIL signale que des modèles issus de plateformes collaboratives peuvent contenir des fichiers corrompus ou des portes dérobées. La chaîne de validation proposée comprend :

  • un téléchargement contrôlé depuis une source identifiée, avec vérification de l'historique de publication, de la licence, des fichiers de configuration et des scripts de chargement associés ;
  • un contrôle d'intégrité par hash, une signature lorsqu'elle existe, un scan antimalware adapté et une quarantaine avant tout usage ;
  • un refus systématique d'exécuter du code sérialisé inconnu, en privilégiant des formats de poids qui ne permettent pas d'embarquer du code, comme safetensors ou GGUF ;
  • un test hors production, une évaluation de comportement puis une approbation formelle tracée.

Un CI/CD qui bloque

Les comptes de build sont séparés, les runners isolés, les secrets absents des Dockerfiles et de l'historique Git. La promotion se fait d'environnement en environnement. Un contrôle bloquant refuse l'image si elle tourne en root, expose des ports inutiles, contient un secret ou présente une vulnérabilité critique non justifiée.

Ces pratiques répondent à l'alerte CNIL sur les composants récents insuffisamment évalués et aux risques d'empoisonnement des données et du modèle visés par l'article 15 de l'AI Act. Go/no-go avant publication : digest épinglé, scan propre, hash du modèle validé, utilisateur non root, aucun secret.

Configurer un runtime Docker LLM réellement cloisonné

C'est ici que se joue l'essentiel de la sécurité conteneur Docker. La fiche ANSSI sert de socle, en gardant à l'esprit qu'elle exclut explicitement de son périmètre le daemon et la gestion des images : ces deux sujets doivent être traités séparément.

Privilèges et système de fichiers

Le service tourne sous un UID non privilégié, idéalement avec Docker rootless lorsque l'architecture et le pilote GPU le permettent. Le système de fichiers racine est en lecture seule, avec des tmpfs limités aux répertoires temporaires nécessaires. Toutes les capacités Linux sont supprimées puis réintroduites une à une si besoin, le profil seccomp par défaut reste actif et l'option no-new-privileges empêche toute élévation. Le mode --privileged est interdit. Monter /var/run/docker.sock dans un conteneur revient en pratique à lui donner un contrôle très large sur l'hôte.

Volumes, secrets et GPU

Les poids sont montés en lecture seule, séparés du cache, des données RAG et des journaux. Aucun montage de l'hôte sans justification écrite. Les secrets passent par un gestionnaire dédié, avec rotation documentée, jamais par l'image. L'accès au périphérique et au runtime NVIDIA élargit la surface d'attaque : n'attribuez que les GPU nécessaires et surveillez les conteneurs ayant accès à la VRAM.

Réseau et ressources

Seul le reverse proxy publie un port ; le serveur d'inférence reste sur un réseau interne. Interface, API, base vectorielle et administration sont segmentées, et l'accès Internet est coupé si le cas d'usage ne l'exige pas. Les limites CPU, mémoire, PIDs, connexions et taille de requête réduisent le déni de service ; une réservation garantit un minimum, une limite fixe un plafond.

services:
  inference:
    image: registre.interne/llm@sha256:<digest>
    user: "10001:10001"
    read_only: true
    tmpfs: ["/tmp:size=256m"]
    cap_drop: [ALL]
    security_opt: ["no-new-privileges:true"]
    pids_limit: 256
    volumes: ["./models:/models:ro"]
    networks: [backend]
    restart: on-failure:3
networks:
  backend:
    internal: true

Cet exemple est conceptuel : le bon profil dépend du noyau, du runtime, du fournisseur GPU et de l'application. Ajoutez une synchronisation horaire fiable, indispensable pour corréler les journaux, et une politique de redémarrage bornée plutôt que always.

Sécuriser les prompts, le RAG et les interfaces d'un LLM conteneurisé

Un conteneur parfaitement durci ne bloque pas une phrase malveillante. La prompt injection directe consiste pour un utilisateur à faire ignorer les consignes ou à obtenir des informations internes. La prompt injection indirecte est plus insidieuse : l'instruction hostile est cachée dans une page web, un PDF, un ticket ou un document indexé par le RAG. Règle fondamentale : instructions système, données non fiables et outils autorisés sont séparés, et un document récupéré n'est jamais traité comme une instruction de confiance.

Contrôles applicatifs

Les entrées sont validées et normalisées, limitées en taille et en fréquence. Les types de fichiers sont filtrés et l'extraction de texte s'exécute dans un environnement isolé. Les sorties sont contrôlées et les secrets masqués avant affichage. Pour un agent capable d'appeler des outils, le moindre privilège s'applique : liste blanche d'actions, comptes de service dédiés, aucune commande système, connecteurs segmentés, journalisation de chaque appel et validation humaine pour les opérations sensibles. Le filtrage de contenu n'est pas de la sécurité : il doit être combiné à des contrôles réseau, identitaires et métiers.

Confidentialité et fiabilité

Aucune donnée personnelle ou stratégique n'est soumise sans finalité définie. La conservation des prompts est limitée, la pseudonymisation privilégiée, les flux et stockages chiffrés. La CNIL évoque des risques de reconstruction et d'inférence d'appartenance pouvant mener à la divulgation de données d'entraînement. Elle rappelle aussi, dans ses premières précisions sur le déploiement d'une IA générative, que ces systèmes peuvent produire des résultats inexacts mais plausibles. Elle recommande de partir d'un besoin concret, d'encadrer les usages, de choisir un système robuste et de former les utilisateurs.

Cas pratique et matrice

Pour un assistant RAG interne conteneurisé, la méthode proposée associe documents en lecture contrôlée, base vectorielle isolée, outils désactivés par défaut, masquage des secrets et validation humaine de toute action externe.

Menace Contrôle Docker Contrôle applicatif Responsable
Injection indirecte RAG Extraction isolée Séparation instructions/données Équipe applicative
Exfiltration Sortant bloqué Filtrage des sorties RSSI
Abus d'outils Réseau segmenté Liste blanche, validation Responsable métier
Saturation Limites ressources Quotas par utilisateur Exploitation

Superviser le runtime et répondre aux incidents

Sans visibilité, un déploiement durci reste vulnérable à ce qu'on ne voit pas.

Quoi surveiller

Les événements prioritaires sont la création, l'arrêt et le redémarrage de conteneurs, les modifications d'image, les changements de privilèges, les accès aux volumes, les connexions sortantes inhabituelles, les appels à l'API d'administration, les pics de tokens, de CPU, de mémoire ou de VRAM, les échecs d'authentification et les téléchargements inattendus. Distinguez les journaux de diagnostic de ceux qui contiennent des prompts, des données personnelles ou des secrets : minimisation, contrôle d'accès, durée de conservation définie et chiffrement.

Une architecture réaliste

Métriques runtime, logs centralisés, traces applicatives et indicateurs métier alimentent des tableaux de bord : disponibilité, latence, taux d'erreur, ressources, taille des contextes, volume de tokens, taux de refus. Tous les signaux ne doivent pas devenir des alertes, sous peine de les noyer. Une surveillance d'intégrité compare images, binaires, modèles et configurations à une référence connue pour détecter toute dérive.

Le scénario d'incident

  1. Isoler le conteneur ou son réseau, sans le redémarrer, car un redémarrage détruit des preuves et laisse la cause intacte.
  2. Préserver les preuves, puis révoquer et renouveler les secrets et suspendre les comptes compromis.
  3. Vérifier l'hôte et les autres workloads, puis restaurer depuis une image et un modèle validés.
  4. Analyser les données potentiellement exfiltrées, documenter causes et corrections.

Sauvegardes, rollback et contacts d'escalade se testent régulièrement.

Tests et indicateurs

Le cycle de vie intègre scan d'image, tests de configuration, tests d'intrusion, fuzzing des entrées, exercices de prompt injection, revue des permissions d'outils et tests de saturation. L'article 15 du Règlement (UE) 2024/1689 impose robustesse, résilience et cybersécurité aux seuls systèmes à haut risque ; il n'est pas automatiquement applicable à tout LLM, mais constitue un référentiel utile. Pour savoir si votre cas d'usage relève de l'annexe III, consultez cette analyse des systèmes d'IA classés à haut risque. KPI proposés : délai de détection, délai de révocation, couverture des images scannées, pourcentage de conteneurs conformes.

Gouvernance, conformité et ROI d'un déploiement LLM souverain

Les mesures techniques ne valent que si elles s'inscrivent dans une décision documentée.

Analyse de risques et responsabilités

L'analyse porte sur le cas d'usage, les données, les utilisateurs, les dépendances, l'exposition réseau et l'impact d'une fuite, d'une indisponibilité ou d'une manipulation du modèle. Les rôles sont répartis entre fournisseur du modèle, hébergeur, intégrateur, administrateur Docker, responsable métier, RSSI et DPO. Pour les données personnelles, l'article 32 du RGPD impose des mesures adaptées au risque, et une AIPD se justifie lorsque le contexte l'exige. Sécurité, protection des données, qualité du modèle et éthique se complètent mais ne se remplacent pas : le guide ANSSI exclut d'ailleurs explicitement la protection des données de son périmètre.

Ce qu'il faut documenter

Registre des modèles et versions, provenance des poids, licences, architecture, flux, règles de rétention, permissions, résultats de scans, tests, incidents, dérogations et date de revue. Une politique d'usage précise les données interdites, les décisions exigeant une validation humaine et la conduite à tenir face à une sortie suspecte. La formation, exigée par l'article 4 de l'AI Act depuis le 2 février 2025, porte concrètement sur les prompts confidentiels, les documents piégés et les limites des réponses.

La souveraineté sans promesse excessive

Un modèle local réduit la dépendance et maîtrise mieux les flux, mais ne rend pas le système souverain ni sécurisé par lui-même : hébergeur, support, mises à jour, pilotes GPU et accès administrateurs restent à examiner.

Critère API externe Cloud privé Local
Contrôle des flux Faible Moyen à élevé Élevé
Compétences internes Faibles Moyennes Élevées
Coût initial Faible Moyen Élevé
Disponibilité Selon fournisseur Contractuelle À votre charge

ROI et feuille de route

Le coût total inclut GPU, stockage, énergie, exploitation, supervision, mises à jour, tests, formation et coût d'un incident évité. Le calculateur de ROI IA d'IAPRO aide à structurer ces postes. Trajectoire proposée : pilote isolé, industrialisation avec contrôles bloquants, puis amélioration continue.

FAQ — sécurité d'un LLM sous Docker

Un conteneur Docker suffit-il à sécuriser un LLM en production ?

Non. Un conteneur partage le noyau de l'hôte et isole un processus, sans offrir la séparation d'une machine virtuelle. Il faut y ajouter une image vérifiée, un modèle contrôlé, un runtime durci, une segmentation réseau, des contrôles applicatifs contre la prompt injection et une supervision runtime. La sécurité d'un LLM conteneurisé repose sur la défense en profondeur, jamais sur une seule couche technique, aussi solide soit-elle.

Pourquoi faut-il éviter le mode privileged et le montage du socket Docker ?

Le mode privileged lève l'essentiel des restrictions du conteneur et lui donne accès aux périphériques de l'hôte. Monter /var/run/docker.sock permet de piloter le daemon, donc de lancer d'autres conteneurs avec des droits étendus. Dans les deux cas, une compromission du service LLM devient une compromission probable de l'hôte entier et de ses autres workloads.

Comment exécuter un conteneur LLM avec les privilèges minimaux ?

Définissez un UID non privilégié, un système de fichiers racine en lecture seule et des tmpfs limités. Supprimez toutes les capacités Linux, conservez le profil seccomp par défaut et activez no-new-privileges. Montez les poids en lecture seule, plafonnez CPU, mémoire et PIDs, et utilisez Docker rootless lorsque le pilote GPU et l'architecture le permettent.

Faut-il autoriser l'accès Internet à un conteneur qui sert un modèle local ?

Généralement non. Un serveur d'inférence local n'a pas besoin de sortir vers Internet une fois le modèle validé et déployé. Placez-le sur un réseau Docker interne, publiez uniquement le reverse proxy et filtrez les flux sortants. Un accès sortant ouvert facilite l'exfiltration et les téléchargements non contrôlés de modèles ou de dépendances.

Comment vérifier qu'un modèle open source est fiable avant son déploiement ?

Contrôlez la source, l'historique de publication, la licence et les scripts de chargement. Vérifiez le hash, la signature lorsqu'elle existe, puis scannez les fichiers en quarantaine. Privilégiez des formats sans code exécutable comme safetensors ou GGUF. Testez ensuite le comportement hors production et formalisez une approbation tracée dans le registre des modèles.

Quels journaux conserver sans exposer les prompts confidentiels ?

Conservez les événements techniques : démarrages de conteneurs, changements d'image, authentifications, flux réseau, consommation de ressources et erreurs. Limitez la journalisation du contenu des prompts au strict nécessaire, pseudonymisez lorsque possible et masquez les secrets. Appliquez un contrôle d'accès restreint, une durée de conservation définie et un chiffrement des journaux stockés et transférés.

La CNIL impose-t-elle une AIPD pour tout projet de LLM Docker ?

Non. L'AIPD est obligatoire dans les cas prévus par l'article 35 du RGPD, notamment lorsque le traitement présente un risque élevé pour les personnes. La CNIL la recommande toutefois pour les systèmes d'IA traitant des données sensibles ou poursuivant des finalités à risque, car elle structure l'inventaire des risques et des mesures de sécurité.

Comment mesurer le ROI d'un déploiement LLM Docker souverain ?

Additionnez les coûts complets : GPU, stockage, énergie, exploitation, supervision, mises à jour, tests de sécurité et formation. Comparez-les au temps gagné sur les cas d'usage ciblés et au coût d'un incident évité. Comparez aussi avec une API externe et un cloud privé, selon la confidentialité, la latence et les compétences internes disponibles.

Pour aller plus loin avec IAPRO

Avant d'exposer un LLM à vos équipes, je vous propose un audit de votre architecture Docker et LLM : revue de l'image, du modèle, du runtime, du RAG et de la supervision, puis trajectoire de sécurisation priorisée selon vos risques réels. La souveraineté n'est pas un argument marketing : c'est un niveau de contrôle qui se démontre. Pour en discuter, contactez IAPRO.

Vérifiez vos aides en 2 minutes

Chaque dispositif (Bpifrance, France Num, aides régionales, OPCO) a ses propres critères d'éligibilité et ses propres délais. Notre simulateur croise votre profil avec les dispositifs actifs, ou échangez directement avec un expert IAPRO.

Vérifier mon éligibilité Demander un diagnostic gratuit de 30 min

Vérifiez vos aides en 2 minutes

Votre projet IA est peut-être finançable à 40-80 %. Le simulateur IAPRO croise 14 dispositifs (Bpifrance, Région Hauts-de-France, OPCO, CIR) et vous envoie le détail par email.

Vérifier mon éligibilité Demander un diagnostic gratuit de 30 min

Liens utiles