Docker pour les agents et bots (Sandboxing de conteneurs)

1. Vue d'ensemble du concept et problème systémique

Le lancement d'agents autonomes, de scrapers, de bots et de scripts de génération de code directement dans le système d'exploitation du serveur (par exemple, via un appel direct à python agent.py ou node bot.js) crée des menaces critiques :

• Erreurs catastrophiques et injections : Un modèle disposant d'un outil d'exécution de commandes shell peut accidentellement supprimer le répertoire de travail du projet, modifier les permissions sur /etc/shadow ou exfiltrer les variables d'environnement de l'hôte.
• Conflits de dépendances (« Dependency Hell ») : Un bot nécessite Node.js 18 et Python 3.10, tandis qu'un autre exige Node.js 22 et les bibliothèques système Chromium pour Playwright. Tenter de les déployer sur le même hôte corrompt les paquets système.
• Épuisement mémoire (Fork Bombs) : Une boucle autonome infinie peut générer des milliers de processus parallèles, provoquant un Kernel Panic ou un gel complet du serveur.

Docker pour agents et bots assure une conteneurisation déterministe et une isolation robuste (Sandboxing). En utilisant les primitives intégrées au noyau Linux, le conteneur crée une capsule éphémère légère où l'agent dispose de toutes les utilitaires nécessaires, mais ne peut pas affecter le système hôte ni les services voisins.

2. Taxonomie architecturale et modèle mental

L'architecture d'isolation sécurisée des agents repose sur trois niveaux de contrôle du noyau Linux :

┌─────────────────────────────────────────────────────────────┐
│                 ARCHITECTURE DU SANDBOX AGENT DOCKER        │
├─────────────────────────────────────────────────────────────┤
│ 1. Isolation des processus (Namespaces Linux) :             │
│    • PID (L'agent ne voit que ses propres processus)        │
│    • NET (Pile réseau isolée, paires veth)                  │
│    • MNT (Système de fichiers racine rootfs dédié)          │
├─────────────────────────────────────────────────────────────┤
│ 2. Encadrement des ressources (Control Groups - cgroups v2):│
│    • Limite mémoire (par ex., max 1,5 Go de RAM)            │
│    • Quota CPU (par ex., max 1 cœur)                        │
│    • Limite PIDs (protection contre le fork infini de       │
│      processus)                                             │
├─────────────────────────────────────────────────────────────┤
│ 3. Couche de durcissement de la sécurité :                  │
│    • Utilisateur non privilégié (`USER nonroot` au lieu     │
│      du UID 0)                                              │
│    • Système de fichiers racine en lecture seule            │
│      (`--read-only`)                                        │
│    • Suppression des capacités Linux (`--cap-drop=ALL`)     │
├─────────────────────────────────────────────────────────────┤
│ 4. Intégration à l'hôte : Volumes nommés & Vérifications    │
│    d'intégrité (Health Checks)                              │
└─────────────────────────────────────────────────────────────┘

1. Espaces de noms (Linux Namespaces) :
   • Assurent la virtualisation des processus, du réseau et du système de fichiers. L'agent à l'intérieur du conteneur se perçoit comme un OS distinct et n'a aucun accès aux processus de l'hôte.
2. Groupes de contrôle (cgroups v2) :
   • Quotas matériels stricts : limites de RAM, CPU et nombre de threads. Si le script de l'agent commence à fuir en mémoire, le OOM-killer de Linux tue uniquement le conteneur, sans toucher aux services principaux du serveur.
3. Conteneurs jetables éphémères (Throwaway Sandboxes) :
   • Lancement avec le flag --rm. Après l'exécution du code, le conteneur s'autodétruit ainsi que toutes les modifications temporaires.
4. Politiques de redémarrage (Restart Policies) :
   • Pour les bots longue durée, la directive restart: unless-stopped dans docker-compose.yml garantit une remontée immédiate du service après un redémarrage du VPS.

3. Pipeline technique et mécanique interne

Cycle de vie de l'exécution sécurisée de code non vérifié dans un sandbox d'agent :

1. Formulation de la tâche et création de la configuration : L'agent IA génère un script (par exemple, du code Python pour parser des données financières).
2. Préparation d'un volume isolé : Le système hôte crée un dossier temporaire /tmp/sandbox-run-981, y écrit le script et définit les permissions pour un utilisateur non privilégié UID 1000.
3. Lancement d'un conteneur jetable sécurisé : L'orchestrateur initie la commande avec une réinitialisation complète des privilèges :

   docker run --rm \
     --network none \
     --memory 512m \
     --cpus 1.0 \
     --pids-limit 64 \
     --read-only \
     --tmpfs /tmp:rw,noexec,nosuid,size=64m \
     --user 1000:1000 \
     -v /tmp/sandbox-run-981:/app:ro \
     python:3.12-slim python /app/script.py
   

4. Exécution isolée : Le script s'exécute :
   • Le réseau est entièrement désactivé (--network none), empêchant toute fuite de données vers le cloud de l'attaquant.
   • Le système de fichiers est accessible en lecture seule (--read-only).
   • L'écriture n'est autorisée que sur un petit disque temporaire en RAM (/tmp).
5. Lecture de la sortie et nettoyage : Les flux STDOUT et STDERR sont renvoyés au cœur de l'agent, puis le répertoire temporaire est supprimé en une fraction de seconde.

4. Scénarios d'ingénierie pratiques en production

01. Stack de production résilient pour un bot Telegram

Déploiement du bot via docker-compose.yml :

services:
  bot:
    build: .
    restart: unless-stopped
    environment:
      - BOT_TOKEN=${BOT_TOKEN}
      - DATABASE_URL=postgres://user:pass@db:5432/botdb
    depends_on:
      db:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 512M

  db:
    image: postgres:17-alpine
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d botdb"]
      interval: 10s

volumes:
  pgdata:

• Le bot redémarre automatiquement en cas de crashs mémoire imprévus, tandis que les données de la base sont conservées dans un volume persistant pgdata.

02. Lancement isolé d'un agent navigateur Playwright

Tests automatisés et parsing de SPA complexes :

• L'agent démarre un conteneur avec Chromium headless installé.
• Les onglets de navigateur figés ou les animations lourdes consomment uniquement la mémoire virtuelle allouée au conteneur, sans surcharger la station de travail.

03. Exécution par lots de scripts utilisateurs non vérifiés

Plateforme de test de code en ligne :

• Chaque test utilisateur s'exécute dans son propre conteneur avec un timeout strict de 5 secondes, empêchant le gel du serveur dû à des boucles infinies while(true).

5. Pièges courants, erreurs typiques et sécurité

• Perte de données due à l'absence de volumes (Volume Absence) : Si vous déployez un conteneur de base de données sans monter un volume persistant (volumes: - db_data:/var/lib/postgresql/data), la moindre mise à jour de l'image ou la commande docker compose down effacera définitivement toute la base de données client.
• Exécution par défaut sous Root : Si la directive USER appuser n'est pas spécifiée dans le Dockerfile, les processus à l'intérieur du conteneur s'exécutent avec les privilèges superutilisateur (UID 0). En cas de vulnérabilité du noyau (Container Escape), l'attaquant obtient instantanément un root complet sur le serveur hôte.
• Saturation du disque par des images inutilisées : Les builds réguliers d'images d'agents laissent derrière eux des gigaoctets de couches « orphelines ». Configurez une commande de nettoyage hebdomadaire : docker system prune -af --volumes.
• Ignorance du .dockerignore : Si le fichier .dockerignore n'est pas créé, les dossiers node_modules, .git et les fichiers secrets locaux .env seront copiés à l'intérieur de l'image publique du conteneur lors du build.