Worker Node

In Produktionsumgebungen sollte die Ausführung nicht vertrauenswürdiger Tools nicht auf demselben System wie PentAGI erfolgen. Ein Worker Node hostet die Agent-Container hinter TLS-geschützten Docker-Endpunkten, sodass Befehle, die ein Agent ausführt, niemals das Hauptsystem erreichen.

Warum ein Worker Node

• Isolation. Tool-Container werden auf dedizierter Hardware mit eigener Netzwerkgrenze ausgeführt.
• Kontrollierter Docker-Zugriff. Agents, die Docker benötigen, kommunizieren über eine Autorisierungsrichtlinie mit einem gehärteten Docker-in-Docker-Daemon statt mit dem Host-Daemon.
• Out-of-Band-Tests. Ein dedizierter Portbereich auf dem Worker Node unterstützt OOB-Callbacks.

Verbindungsmodi

• Standard (empfohlen) — PentAGI verbindet sich über TLS mit dem Host-Docker des Worker Node, um Worker-Container zu erstellen; Worker erreichen Docker-in-Docker über dessen TLS-Endpunkt. Setzen Sie DOCKER_INSIDE=true zusammen mit DOCKER_INSIDE_HOST, DOCKER_INSIDE_TLS_VERIFY und DOCKER_INSIDE_CERT_PATH, und lassen Sie DOCKER_SOCKET leer: Die /var/run/docker.sock der Vorlage .env würde sonst den Host-Docker-Socket des Worker Node in jede Sandbox einbinden. Ohne DOCKER_INSIDE_HOST erhalten die Agenten keinen Docker-Zugriff.
• Direkt — PentAGI kommuniziert direkt mit Docker-in-Docker; Host-Bind-Mounts werden dann durch Richtlinien abgelehnt, daher muss der Docker-Zugriff für Agents deaktiviert werden.

Einrichtung

Das vollständige Verfahren — TLS-Zertifikate für beide Daemons, die gehärtete Docker-in-Docker-Konfiguration, Richtlinienaktualisierungen und Verifizierung — finden Sie im Worker-Node-Leitfaden im Repository.