Worker node

En production, évitez d'exécuter des tools non fiables sur la machine qui exécute PentAGI. Un worker node héberge les conteneurs des agents derrière des points de terminaison Docker protégés par TLS, afin que les commandes exécutées par un agent n'atteignent jamais l'hôte principal.

Pourquoi utiliser un worker node

• Isolation. Les conteneurs de tool s'exécutent sur du matériel dédié avec leur propre périmètre réseau.
• Accès Docker contrôlé. Les agents nécessitant Docker communiquent avec un démon Docker-in-Docker durci via une politique d'autorisation, plutôt qu'avec le démon de l'hôte.
• Tests hors bande. Une plage de ports dédiée sur le worker node prend en charge les rappels hors bande.

Modes de connexion

• Standard (recommandé) — PentAGI se connecte au Docker hôte du worker node via TLS pour créer les conteneurs worker ; les workers accèdent à Docker-in-Docker via son point de terminaison TLS. Définissez DOCKER_INSIDE=true conjointement avec DOCKER_INSIDE_HOST, DOCKER_INSIDE_TLS_VERIFY et DOCKER_INSIDE_CERT_PATH, et laissez DOCKER_SOCKET vide : le /var/run/docker.sock du template .env monterait également le socket Docker hôte du worker node dans chaque sandbox. Sans DOCKER_INSIDE_HOST, les agents n’ont aucun accès à Docker.
• Direct — PentAGI communique directement avec Docker-in-Docker ; les montages bind de l'hôte sont alors refusés par la politique, et l'accès Docker pour les agents doit donc être désactivé.

Configuration

La procédure complète — certificats TLS pour les deux démons, configuration durcie de Docker-in-Docker, mises à jour des politiques et vérification — est détaillée dans le guide du worker node du dépôt.