Docker für Agenten und Bots (Container-Sandboxing)

1. Konzeptüberblick und systemische Problematik

Der Start autonomer Agenten, Scraper, Bots und Code-Generierungsskripte direkt im Betriebssystem des Servers (z. B. durch direkten Aufruf von python agent.py oder node bot.js) birgt kritische Risiken:

• Katastrophale Fehler und Injection-Angriffe: Ein Modell, dem das Tool zur Ausführung von Shell-Befehlen gewährt wird, kann versehentlich das Arbeitsverzeichnis des Projekts löschen, Zugriffsrechte auf /etc/shadow ändern oder System-Umgebungsvariablen des Hosts leaken.
• Abhängigkeitskonflikte („Dependency Hell“): Ein Bot erfordert Node.js 18 und Python 3.10, ein anderer benötigt Node.js 22 sowie die Chromium-Systembibliotheken für Playwright. Der Versuch, beide auf einem einzigen Host bereitzustellen, führt zu Konflikten bei den Systempaketen.
• Speichererschöpfung (Fork Bombs): Endlose autonome Schleifen können Tausende parallele Prozesse erzeugen, was zu einem Kernel Panic oder einem vollständigen Einfrieren des Servers führt.

Docker für Agenten und Bots bietet deterministische Containerisierung und robuste Isolation (Sandboxing). Unter Nutzung der eingebetteten Primitiven des Linux-Kernels erstellt der Container eine leichtgewichtige, ephemere Kapsel, in der der Agent alle erforderlichen Utilities erhält, jedoch keinen Einfluss auf das Host-System oder benachbarte Services nehmen kann.

2. Architektonische Taxonomie und mentales Modell

Die Architektur einer sicheren Agenten-Isolation stützt sich auf drei Kontrollschichten des Linux-Kernels:

┌─────────────────────────────────────────────────────────────┐
│                 DOCKER AGENT SANDBOX ARCHITECTURE           │
├─────────────────────────────────────────────────────────────┤
│ 1. Process Isolation (Linux Namespaces):                    │
│    • PID (Агент бачить лише власні процеси)                 │
│    • NET (Ізольований мережевий стек, veth pairs)           │
│    • MNT (Власна коренева файлова система rootfs)           │
├─────────────────────────────────────────────────────────────┤
│ 2. Resource Enclosure (Control Groups - cgroups v2):        │
│    • Memory limit (наприклад, max 1.5GB RAM)                │
│    • CPU quota (наприклад, max 1 core)                      │
│    • PIDs limit (захист від нескінченного форку процесів)   │
├─────────────────────────────────────────────────────────────┤
│ 3. Security Hardening Layer:                                │
│    • Unprivileged User (`USER nonroot` замість UID 0)       │
│    • Read-Only Root Filesystem (`--read-only`)              │
│    • Dropped Linux Capabilities (`--cap-drop=ALL`)          │
├─────────────────────────────────────────────────────────────┤
│ 4. Host Integration: Named Volumes & Health Checks          │
└─────────────────────────────────────────────────────────────┘

1. Namespaces (Linux Namespaces):
   • Stellen Virtualisierung von Prozessen, Netzwerk und Dateisystem bereit. Der Agent innerhalb des Containers sieht sich als eigenständiges OS und hat keinen Zugriff auf die Prozesse des Hosts.
2. Control Groups (cgroups v2):
   • Strikte Hardware-Quotas: Limits für RAM, CPU und Thread-Anzahl. Wenn das Skript des Agenten beginnt, Speicher zu leakan, tötet der Linux OOM-Killer nur den Container, ohne die Kernservices des Servers zu beeinträchtigen.
3. Ephemere Einweg-Container (Throwaway Sandboxes):
   • Start mit dem Flag --rm. Nach der Ausführung des Codes zerstört sich der Container selbst mitsamt aller temporären Änderungen.
4. Neustart-Richtlinien (Restart Policies):
   • Für langlebige Bots garantiert die Direktive restart: unless-stopped in der docker-compose.yml einen sofortigen Neustart des Services nach einem VPS-Reboot.

3. Technischer Pipeline und interne Mechanik

Der Lebenszyklus der sicheren Ausführung unverifizierten Codes in einer Agenten-Sandbox:

1. Aufgabenformulierung und Konfigurationserstellung: Der KI-Agent generiert ein Skript (z. B. Python-Code zum Parsen finanzieller Daten).
2. Vorbereitung eines isolierten Volumes: Das Host-System erstellt einen temporären Ordner /tmp/sandbox-run-981, schreibt das Skript hinein und setzt die Rechte auf einen nicht privilegierten Benutzer (UID 1000).
3. Start eines geschützten Einweg-Containers: Der Orchestrator initiiert den Befehl mit vollständigem Privilegien-Reset:

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.  **Isolierte Ausführung:**
 Das Skript wird ausgeführt:
 *   Das Netzwerk ist vollständig deaktiviert (`--network none`), was ein Leaken von Daten an die Cloud des Angreifers unmöglich macht.
 *   Das Dateisystem ist nur lesbar zugänglich (`--read-only`).
 *   Schreibzugriff ist nur auf einen kleinen temporären Disk im RAM (`/tmp`) erlaubt.
5.  **Auslesen der Ausgabe und Bereinigung:**
 Die Streams `STDOUT` und `STDERR` werden zurück an den Agent-Core übergeben, woraufhin das temporäre Verzeichnis binnen Sekundenbruchteilen gelöscht wird.

## 4. Praktische Engineering-Szenarien im Production

### 01. Ausfallsicheres Production-Stack für Telegram-Bots

Deployment des Bots mittels `docker-compose.yml`:
```yaml
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:

• Der Bot startet automatisch neu bei unvorhergesehenen Memory-Crashes, während die Datenbankdaten im persistenten Volume pgdata gespeichert bleiben.

02. Isolierter Start eines Browser-Agents mit Playwright

Automatisiertes Testing und Parsing komplexer SPAs:

• Der Agent startet einen Container mit installiertem headless Chromium.
• Hängende Browsertabs oder schwere Animationen verbrauchen nur den zugewiesenen virtuellen Speicher des Containers und belasten nicht die Workstation.

03. Batch-Ausführung unverifizierter User-Skripte

Plattform für Online-Code-Testing:

• Jeder User-Test läuft in einem eigenen Container mit einem harten Timeout von 5 Sekunden, was Server-Hangs durch endlose while(true)-Schleifen verhindert.

5. Fallstricke, häufige Fehler und Sicherheit

• Datenverlust durch fehlende Volumes (Volume Absence): Wird ein Datenbank-Container ohne Mount eines persistenten Volumes deployed (volumes: - db_data:/var/lib/postgresql/data), so wird beim ersten Image-Update oder bei docker compose down die gesamte Client-Datenbank unwiderruflich gelöscht.
• Standardmäßiger Betrieb unter Root: Wenn im Dockerfile keine Anweisung USER appuser definiert ist, laufen die Prozesse im Container mit Superuser-Rechten (UID 0). Im Falle einer Kernel-Vulnerability (Container Escape) erhält der Angreifer sofort vollen Root-Zugriff auf den Host-Server.
• Disk-Füllstand durch ungenutzte Images: Regelmäßige Builds der Agenten-Images hinterlassen Gigabytes an „verwaisten“ Layern. Richten Sie einen wöchentlichen Cleanup-Befehl ein: docker system prune -af --volumes.
• Ignorieren der .dockerignore: Wenn keine .dockerignore-Datei erstellt wird, werden Ordner wie node_modules, .git sowie lokale Secret-Dateien .env während des Build-Prozesses in das öffentliche Container-Image kopiert.