Worker node

En producción, mantén la ejecución de tool no confiable fuera de la máquina que ejecuta PentAGI. Un worker node aloja los contenedores de los agents detrás de endpoints de Docker protegidos por TLS, de modo que los comandos que ejecuta un agent nunca afectan al host principal.

Por qué un worker node

• Aislamiento. Los contenedores de tool se ejecutan en hardware dedicado con su propio límite de red.
• Acceso a Docker controlado. Los agents que necesitan Docker se comunican con un daemon Docker-in-Docker endurecido mediante una política de autorización en lugar del daemon del host.
• Pruebas out-of-band. Un rango de puertos dedicado en el worker node admite callbacks OOB.

Modos de conexión

• Estándar (recomendado) — PentAGI se conecta al Docker del host del worker node mediante TLS para crear contenedores worker; los workers acceden a Docker-in-Docker a través de su endpoint TLS. Configura DOCKER_INSIDE=true junto con DOCKER_INSIDE_HOST, DOCKER_INSIDE_TLS_VERIFY y DOCKER_INSIDE_CERT_PATH, y deja DOCKER_SOCKET vacío: el /var/run/docker.sock de la plantilla .env también montaría el socket de Docker del host del worker node en cada sandbox. Sin DOCKER_INSIDE_HOST, los agents no obtienen acceso a Docker.
• Directo — PentAGI se comunica directamente con Docker-in-Docker; los bind-mounts del host son denegados por política, por lo que el acceso a Docker para los agents debe estar deshabilitado.

Configuración

El procedimiento completo — certificados TLS para ambos daemons, la configuración endurecida de Docker-in-Docker, actualizaciones de políticas y verificación — está en la guía del worker node en el repositorio.