Worker node

Em produção, mantenha a execução de tool não confiável fora da máquina que roda o PentAGI. Um worker node hospeda os containers dos agents atrás de endpoints Docker protegidos por TLS, de modo que os comandos executados por um agent nunca tocam o host principal.

Por que usar um worker node

• Isolamento. Os containers de tool rodam em hardware dedicado com seu próprio limite de rede.
• Acesso controlado ao Docker. Agents que precisam do Docker se comunicam com um daemon Docker-in-Docker endurecido por meio de uma política de autorização, em vez de usar o daemon do host.
• Testes fora de banda. Uma faixa de portas dedicada no worker node suporta callbacks OOB.

Modos de conexão

• Padrão (recomendado) — O PentAGI se conecta ao Docker do host do worker node via TLS para criar containers worker; os workers acessam o Docker-in-Docker por seu endpoint TLS. Defina DOCKER_INSIDE=true junto com DOCKER_INSIDE_HOST, DOCKER_INSIDE_TLS_VERIFY e DOCKER_INSIDE_CERT_PATH, e deixe DOCKER_SOCKET vazio: o /var/run/docker.sock do template .env também montaria o socket do Docker do host do worker node em cada sandbox. Sem DOCKER_INSIDE_HOST, os agents não têm acesso ao Docker.
• Direto — O PentAGI se comunica diretamente com o Docker-in-Docker; bind-mounts do host são então negados pela política, portanto o acesso ao Docker para os agents deve ser desabilitado.

Configuração

O procedimento completo — certificados TLS para ambos os daemons, a configuração endurecida do Docker-in-Docker, atualizações de política e verificação — está no guia do worker node no repositório.