Worker node

In produzione, tieni l'esecuzione di tool non attendibili fuori dalla macchina che esegue PentAGI. Un worker node ospita i container degli agents dietro endpoint Docker protetti da TLS, in modo che i comandi eseguiti da un agent non tocchino mai l'host principale.

Perché un worker node

• Isolamento. I container dei tool vengono eseguiti su hardware dedicato con il proprio confine di rete.
• Accesso Docker controllato. Gli agents che necessitano di Docker comunicano con un daemon Docker-in-Docker irrobustito tramite una policy di autorizzazione, anziché con il daemon dell'host.
• Test out-of-band. Un intervallo di porte dedicato sul worker node consente le callback out-of-band.

Modalità di connessione

• Standard (consigliata) — PentAGI si connette al Docker host del worker tramite TLS per creare i container worker; i worker raggiungono Docker-in-Docker tramite il suo endpoint TLS. Imposta DOCKER_INSIDE=true insieme a DOCKER_INSIDE_HOST, DOCKER_INSIDE_TLS_VERIFY e DOCKER_INSIDE_CERT_PATH, e lascia DOCKER_SOCKET vuoto: il /var/run/docker.sock del template .env monterebbe anche il socket Docker host del worker node in ogni sandbox. Senza DOCKER_INSIDE_HOST, gli agent non hanno accesso a Docker.
• Diretta — PentAGI comunica direttamente con Docker-in-Docker; i bind-mount dell'host vengono quindi negati dalla policy, perciò l'accesso a Docker per gli agents deve essere disabilitato.

Configurazione

La procedura completa — certificati TLS per entrambi i daemon, configurazione irrobustita di Docker-in-Docker, aggiornamenti delle policy e verifica — è disponibile nella guida al worker node nel repository.