PentAGI 如何搭建独立 Worker 节点：dind TLS、OPA 授权与 seccomp 加固流程

PentAGI 如何搭建独立 Worker 节点：dind TLS、OPA 授权与 seccomp 加固流程

【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi

如果你的 PentAGI 主节点要执行真实的渗透测试任务，官方建议把 agent 的执行环境隔离到一台独立服务器上——主节点只负责管理，worker 节点承担所有容器操作。这篇文章按照仓库中的 Worker Node Setup 指南 走一遍完整流程：在 worker 节点上配置 host Docker 的 TLS 远程 API（:2376），再部署一个三层加固的 Docker-in-Docker（dind）（:3376，TLS + OPA 授权插件 + seccomp 内核过滤），然后把证书和连接配置接回主节点，最终让 PentAGI 的 worker 容器全部运行在这个受控沙箱里。

适用前提：主节点和 worker 节点各一台 Ubuntu 服务器，能互相访问私有网络；主节点负责跑 PentAGI 容器，worker 节点负责跑pentagi-terminal-N工作容器及其嵌套容器。

架构与连接模式

worker 节点上运行两个 Docker 守护进程：

• Host Docker（:2376，TLS）：PentAGI 通过它创建工作容器pentagi-terminal-N；
• dind（:3376，TLS + OPA + seccomp）：agent 在 worker 容器内执行docker run时实际打到的端点，所有嵌套容器创建请求都会经过授权策略检查。

两种连接模式（指南中推荐Standard）：

模式	链路	特点
Standard（推荐）	PentAGI → Host Docker →（创建 worker）→ worker 经 TLS 访问 dind	agent 保留完整 Docker 能力，每个嵌套容器都受 dind 授权策略约束
Direct	PentAGI 直接连 dind 创建 worker	worker 本身成为嵌套容器，策略同样约束它：host bind-mount 被拒绝，因此必须禁用 Docker Access 且 Work Directory 留空，agent 也没有嵌套 Docker

指南专门解释了为什么 worker 容器通过 TLS 端点而不是挂载 socket 访问 dind：挂载一个尚不存在的 socket 文件时，Docker 会在节点重启后把它物化成一个目录，导致 dind 无法在重启后绑定 socket；而如果改挂 host daemon 的 socket 来规避这个竞态，等于把整个 host Docker 交给了自主运行的 agent（可以起特权容器、挂载/接管节点）。指向tcp://${PRIVATE_IP}:3376两端都不存在这些问题，且客户端证书是只读挂载，agent 能用但不能改写。

准备：变量与两节点安装 Docker

在 worker 节点上先定义本次搭建要用的变量（PRIVATE_IP换成 worker 节点实际 IP）：

export PRIVATE_IP=192.168.10.10 # Replace with your worker node IP export METRICS_IP=127.0.0.1 # Bind address for metrics ports 8080 / 9100 / 9323 / 9324

METRICS_IP默认127.0.0.1，指标端口只对 worker 节点本机可见；只有需要远程 Prometheus 抓取时才改成${PRIVATE_IP}。

Docker 必须在两个节点上都安装，按官方 Ubuntu 安装方式执行（在每个节点分别运行）：

# Add Docker's official GPG key sudo apt-get update sudo apt-get install ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc # Add Docker repository to APT sources echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update # Install Docker CE and plugins sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

第一步：Host Docker 开启 TLS（:2376）

生成 host Docker 的证书

# Install easy-rsa for certificate management sudo apt install easy-rsa # Create PKI infrastructure for host docker sudo mkdir -p /etc/easy-rsa/docker-host cd /etc/easy-rsa/docker-host sudo /usr/share/easy-rsa/easyrsa init-pki sudo /usr/share/easy-rsa/easyrsa build-ca nopass # Generate server certificate with SAN extensions export EASYRSA_EXTRA_EXTS="subjectAltName = @alt_names [alt_names] DNS.1 = localhost DNS.2 = docker DNS.3 = docker-host IP.1 = 127.0.0.1 IP.2 = ${PRIVATE_IP}" sudo -E /usr/share/easy-rsa/easyrsa build-server-full server nopass # Confirm with 'yes' unset EASYRSA_EXTRA_EXTS # Generate client certificate sudo /usr/share/easy-rsa/easyrsa build-client-full client nopass # Confirm with 'yes' # Copy server certificates to Docker directory sudo mkdir -p /etc/docker/certs/server sudo install -m 0444 pki/ca.crt /etc/docker/certs/server/ca.pem sudo install -m 0444 pki/issued/server.crt /etc/docker/certs/server/cert.pem sudo install -m 0400 pki/private/server.key /etc/docker/certs/server/key.pem # Copy client certificates for remote access sudo mkdir -p /etc/docker/certs/client sudo install -m 0444 pki/ca.crt /etc/docker/certs/client/ca.pem sudo install -m 0444 pki/issued/client.crt /etc/docker/certs/client/cert.pem sudo install -m 0400 pki/private/client.key /etc/docker/certs/client/key.pem

两个容易踩的坑，文档都明确标注了：build-server-full前必须exportSAN 扩展，且执行时用sudo -E让EASYRSA_EXTRA_EXTS传进 easy-rsa——否则签出的证书没有 SAN，所有 TLS 客户端都会拒绝它。证书生成过程中会要求确认，按提示输入yes。

配置 daemon 并开启 TCP 监听

# Configure Docker daemon with TLS settings sudo tee /etc/docker/daemon.json > /dev/null << EOF { "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "2", "compress": "true" }, "dns-opts": [ "ndots:1" ], "metrics-addr": "${METRICS_IP}:9323", "tls": true, "tlscacert": "/etc/docker/certs/server/ca.pem", "tlscert": "/etc/docker/certs/server/cert.pem", "tlskey": "/etc/docker/certs/server/key.pem", "tlsverify": true } EOF # Enable TCP listening on private IP (required for remote access) sudo sed -i "s|ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock|ExecStart=/usr/bin/dockerd -H fd:// -H tcp://${PRIVATE_IP}:2376 --containerd=/run/containerd/containerd.sock|" /lib/systemd/system/docker.service # Apply configuration changes sudo systemctl daemon-reload sudo systemctl restart docker

sed这一步修改的是 systemd 服务单元，往dockerd启动参数里追加tcp://${PRIVATE_IP}:2376监听，是远程 TLS 访问生效的必要条件。

验证 TLS 访问

创建一个客户端包装脚本，后续步骤也会用到：

sudo tee /usr/local/bin/docker-host-tls > /dev/null << EOF #!/bin/bash # Docker API client wrapper for TLS connections # Usage: docker-host-tls [docker-commands] export DOCKER_HOST=tcp://${PRIVATE_IP}:2376 export DOCKER_TLS_VERIFY=1 export DOCKER_CERT_PATH=/etc/docker/certs/client # Show connection info if no arguments provided if [ \$# -eq 0 ]; then echo "Docker API connection configured:" echo " Host: ${PRIVATE_IP}:2376" echo " TLS: enabled" echo " Certificates: /etc/docker/certs/client/" echo "" echo "Usage: docker-host-tls [docker-commands]" echo "Examples:" echo " docker-host-tls version" echo " docker-host-tls ps" echo " docker-host-tls images" exit 0 fi # Execute docker command with TLS environment exec docker "\$@" EOF sudo chmod +x /usr/local/bin/docker-host-tls # Test TLS connection docker-host-tls ps && docker-host-tls info

docker-host-tls ps能列出容器、docker-host-tls info返回守护进程信息，说明:2376端点就绪。

第二步：部署加固版 dind（:3376）

dind 是 agent 真正打到的 Docker 端点，指南把它按"接收不可信输入"对待，在三个相互独立的层面加固：

层面	控制	目的
容器	显式 capability 集合，不用--privileged	dind 自身只保留dockerd需要的最小权限
守护进程 API	OPA 授权插件（authz.rego），fail-closed	在每一次嵌套containers/create和exec中拒绝逃逸原语
内核	守护进程级 seccomp 配置（seccomp.json）	在内核层阻止块设备mknod（文档确认的主要逃逸向量）

为 dind 建立独立 PKI

dind 必须使用自己的 CA，不能与 host Docker 共用：

# Create PKI infrastructure for dind sudo mkdir -p /etc/easy-rsa/docker-dind cd /etc/easy-rsa/docker-dind sudo /usr/share/easy-rsa/easyrsa init-pki sudo /usr/share/easy-rsa/easyrsa build-ca nopass # Generate server certificate with SAN extensions export EASYRSA_EXTRA_EXTS="subjectAltName = @alt_names [alt_names] DNS.1 = localhost DNS.2 = docker-dind IP.1 = 127.0.0.1 IP.2 = ${PRIVATE_IP}" sudo -E /usr/share/easy-rsa/easyrsa build-server-full server nopass # Confirm with 'yes' unset EASYRSA_EXTRA_EXTS # Generate client certificate sudo /usr/share/easy-rsa/easyrsa build-client-full client nopass # Confirm with 'yes' # Create the directory layout dind expects sudo mkdir -p /etc/docker/dind/{scripts,authz,certs/{ca,server,client}} \ /var/lib/docker-dind /var/run/docker-dind # Publish certificates (the CA private key stays in the PKI, never in /certs) sudo install -m 0444 pki/ca.crt /etc/docker/dind/certs/ca/cert.pem sudo install -m 0444 pki/ca.crt /etc/docker/dind/certs/server/ca.pem sudo install -m 0444 pki/issued/server.crt /etc/docker/dind/certs/server/cert.pem sudo install -m 0400 pki/private/server.key /etc/docker/dind/certs/server/key.pem sudo install -m 0444 pki/ca.crt /etc/docker/dind/certs/client/ca.pem sudo install -m 0444 pki/issued/client.crt /etc/docker/dind/certs/client/cert.pem sudo install -m 0400 pki/private/client.key /etc/docker/dind/certs/client/key.pem

dind 的 entrypoint 检测到这套完整证书后会直接使用，不再每次启动生成自签名证书。

部署配置文件

策略、守护进程配置和脚本都随仓库发布，位于 examples/guides/worker_node/，其目录 README 列出了每个文件的安装位置与用途。把该目录下的文件拷贝到 worker 节点/tmp（例如从克隆的仓库scp过去），然后执行安装：

cd /tmp # Daemon policy files — mounted read-only as /etc/docker inside dind sudo install -m 0644 authz.rego daemon.json seccomp.json /etc/docker/dind/authz/ # Custom entrypoint (adds DOCKER_API_HOST and DOCKER_DNS_SERVERS support) sudo install -m 0755 dockerd-entrypoint.sh /etc/docker/dind/scripts/ # Management, wrapper, and maintenance scripts sudo install -m 0755 run-dind.sh /usr/local/bin/run-dind sudo install -m 0755 docker-dind-tls.sh /usr/local/bin/docker-dind-tls sudo install -m 0755 docker-dind-sock.sh /usr/local/bin/docker-dind-sock sudo install -m 0755 dind-cleanup.sh /usr/local/bin/dind-cleanup sudo install -m 0755 policy-tests.sh /usr/local/bin/dind-policy-tests sudo install -m 0644 dind-cleanup.service dind-cleanup.timer /etc/systemd/system/

其中三个策略相关文件的角色：authz.rego 是 OPA 策略（fail-closed 门禁），seccomp.json 是嵌套容器的内核级 syscall 过滤配置，daemon.json 把 seccomp 配置设为 dind 守护进程的全局默认。三者所在目录在 dind 容器内被只读挂载为/etc/docker。

所有脚本只读一个主机级配置文件，按本机情况编辑这一份即可：

sudo tee /etc/docker/dind/dind.env > /dev/null << EOF API_ADDRESS=${PRIVATE_IP} DOCKER_PORT=3376 METRICS_ADDRESS=${METRICS_IP} METRICS_PORT=9324 CPU_LIMIT=2 MEMORY_LIMIT=4G MAX_AGE_HOURS=24 EOF

关键变量与默认值（可省略不写即取默认）：

变量	默认	用途
API_ADDRESS/DOCKER_PORT	0.0.0.0/3376	dind TLS API 绑定地址与端口
METRICS_ADDRESS/METRICS_PORT	127.0.0.1/9324	Prometheus 指标端点
NETWORK	host	host直接绑定在API_ADDRESS上；bridge改为发布端口
CPU_LIMIT/MEMORY_LIMIT/PIDS_LIMIT	2/4G/2048	dind 容器资源限制
DNS_SERVERS	空	逗号分隔，应用于所有嵌套容器
MAX_AGE_HOURS	24	清理 timer 的容器年龄阈值

注意：dind 默认--network host，端口必须与 host Docker 的2376错开，指南要求保持3376除非同时改动 host 端。

启动 dind 并完成 OPA 插件引导

sudo run-dind

run-dind.sh 的首次运行是两阶段引导：dind 先在不启用授权的情况下启动，脚本把 OPA 插件（openpolicyagent/opa-docker-authz-v2:0.9）下载并安装为 dind 守护进程内的 managed plugin，然后带--authorization-plugin重启进入 fail-closed 模式。插件持久化在/var/lib/docker-dind，之后的启动会直接带策略启动。

启动后按这四条命令逐一确认守护进程、插件和两条访问路径：

docker ps | grep docker-dind # dind container is up docker-dind-sock plugin ls # opa-docker-authz is enabled docker-dind-sock run --rm hello-world # nested containers work docker-dind-tls version # TLS endpoint answers curl -s http://${METRICS_IP}:9324/metrics | head -5

加固策略实际在拦什么

dind 容器本身以--cap-drop ALL启动，只加回dockerd需要的 capabilities（SYS_ADMIN、NET_ADMIN、NET_RAW、SETUID、SETGID、MKNOD、FOWNER、DAC_OVERRIDE、CHOWN、AUDIT_WRITE、KILL、SYS_CHROOT、FSETID、SETFCAP、SETPCAP、NET_BIND_SERVICE）。

authz.rego对containers/create和exec默认allow = false，以下请求对嵌套容器一律拒绝：

拒绝项	覆盖范围
--privileged	容器创建与 exec
白名单外的--cap-add	SYS_ADMIN、MKNOD、ALL等
--device、--device-cgroup-rule	设备直通与 cgroup 规则注入
--security-opt	seccomp / AppArmor / systempaths 覆盖
--pid、--ipc、--userns、--cgroupns、--uts共享	host 与跨容器命名空间
显式MaskedPaths/ReadonlyPaths	移除/proc/sys保护 →modprobe_pathhost 逃逸
Host bind-mounts	-v /host:/dest与--mount type=bind全部
--sysctl、DeviceRequests、非runc--runtime、CgroupParent	其余提权字段
docker cp、commit、build、image load、plugin install、Swarm	绕过创建门禁的 API 端点
带 bind 仿真的volume create、macvlan/ipvlan 的network create	挂载与 L2 直通仿真

同时保留合法渗透测试负载所需：默认 capability 集加NET_ADMIN/NET_RAW、Docker 管理卷、tmpfs、docker pull、完整容器生命周期、bridge 网络与--network host。

块设备逃逸做了双重封锁：MKNOD在 Docker 默认 capability 集里无法移除，seccomp.json因此在内核层对带S_IFBLK标志的mknod/mknodat直接返回SCMP_ACT_ERRNO（字符设备刻意放行，供/dev/net/tun等渗透工具使用），authz.rego同时封死--cap-add MKNOD和一切--security-opt覆盖，保证该 profile 无法被替换或禁用。两者共同拒绝mknod /dev/sda b 8 0+debugfs直读 host 磁盘的路径。

一个明确的边界要说清楚：--network host是有意放行的（渗透工具需要 raw socket 和 host 本地目标），因此嵌套容器能到达 worker 节点网络栈上的所有服务，包括 host Docker 的 TLS 端口。文档要求：绝不在 worker 节点存放外层守护进程的客户端证书，也绝不在其上暴露任何提供文件服务的明文 HTTP 端口。

第三步：策略更新与自动清理

修改策略后不能只重启，因为旧策略下创建的嵌套容器保留原HostConfig。run-dind记录authz.rego的 SHA-256 于/var/lib/docker-dind/.authz-policy-hash，哈希变化时会临时无授权启动、强制删除所有嵌套容器、再带新策略重启：

# After editing /etc/docker/dind/authz/authz.rego sudo docker rm -f docker-dind && sudo run-dind # Force a purge without a policy change sudo env PURGE=yes /usr/local/bin/run-dind

worker 容器是短生命周期的，启用清理 timer 按MAX_AGE_HOURS自动清理：

sudo systemctl daemon-reload sudo systemctl enable --now dind-cleanup.timer systemctl status dind-cleanup.timer # check schedule journalctl -u dind-cleanup.service -n 50 # review last run sudo env MAX_AGE_HOURS=1 /usr/local/bin/dind-cleanup # run manually with an override

第四步：运行隔离测试套件验证

dind-policy-tests在"与真实 PentAGI worker 完全同配置"的容器里演练授权策略和 seccomp profile：正向测试覆盖合法负载（nmap、masscan、curl、sqlmap、nginx、卷、tmpfs、容器生命周期），负向测试覆盖逃逸原语（特权容器、危险 capability、host 命名空间、bind-mount、块设备mknod、nsenter）。指南要求在部署完成后以及每次策略变更后各跑一次。

套件会探测节点上的一个明文 HTTP 服务，先安装 Python 并启动一个临时服务器，然后运行测试容器：

sudo apt-get install -y python3 python3 -m http.server 8080 --bind "${PRIVATE_IP}" >/tmp/dind-test-http.log 2>&1 & HTTP_PID=$! docker run --rm -it \ --name pentagi-terminal-test \ --network host \ --cap-add NET_ADMIN --cap-add NET_RAW \ -e TARGET_IP=${PRIVATE_IP} \ -e HTTP_PORT=8080 \ -e DIND_TLS_PORT=3376 \ -e OUTER_TLS_PORT=2376 \ -e DOCKER_HOST=tcp://${PRIVATE_IP}:3376 \ -e DOCKER_TLS_VERIFY=1 \ -e DOCKER_CERT_PATH=/etc/docker/dind/certs/client \ -v /usr/local/bin/dind-policy-tests:/work/policy-tests.sh:ro \ -v /etc/docker/dind/certs/client:/etc/docker/dind/certs/client:ro \ -w /work \ vxcontrol/kali-linux \ bash /work/policy-tests.sh kill "${HTTP_PID}" 2>/dev/null || true

这个调用方式精确复现了 PentAGI 对真实 worker 容器的注入：dind 端点与客户端证书通过环境变量提供，不挂载任何 Docker socket。判定标准：每项测试报告[ PASS ]或[ SKIP ]，无失败时退出码为0。文档对两类失败给出明确含义——负向测试失败意味着存在隔离缺口，必须停下来处理；正向测试失败是误报，会直接打断 agent 工作负载。

把证书传到主节点并接入 PentAGI

传输两组客户端证书

# On the worker node - create archive with host docker certificates sudo tar czf docker-host-ssl.tar.gz -C /etc/docker/certs client/ # Transfer to main node (replace <MAIN_NODE_IP> with actual IP) scp docker-host-ssl.tar.gz root@<MAIN_NODE_IP>:/opt/pentagi/ # On the main node - extract certificates cd /opt/pentagi tar xzf docker-host-ssl.tar.gz mv client docker-host-ssl rm docker-host-ssl.tar.gz

# On the worker node - create archive with dind certificates sudo tar czf docker-dind-ssl.tar.gz -C /etc/docker/dind/certs client/ # Transfer to main node (replace <MAIN_NODE_IP> with actual IP) scp docker-dind-ssl.tar.gz root@<MAIN_NODE_IP>:/opt/pentagi/ # On the main node - extract certificates cd /opt/pentagi tar xzf docker-dind-ssl.tar.gz mv client docker-dind-ssl rm docker-dind-ssl.tar.gz

验证主节点上的目录结构，两个目录各应包含ca.pem、cert.pem、key.pem：

ls -la /opt/pentagi/docker-host-ssl/ ls -la /opt/pentagi/docker-dind-ssl/

文档要求这两组证书目录仅 root 可读，且位于任何 HTTP 服务的目录之外。

主节点安装并配置 Docker 环境

# Create installation directory and navigate to it mkdir -p /opt/pentagi && cd /opt/pentagi # Download the latest installer wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip # Extract the installer unzip installer.zip # Run the installer (interactive setup) sudo ./installer

installer 需要与 Docker API 交互，生产环境按文档建议用 root 运行。安装完成后，通过./installer进入Tools → Docker Environment填写 Standard 模式配置：

PentAGI 如何到达 worker 节点（host Docker）：

• Docker Host：tcp://${PRIVATE_IP}:2376
• TLS Verification：1
• TLS Certificates：/opt/pentagi/docker-host-ssl（主节点上的路径，会挂进 PentAGI 容器）

worker 容器如何到达 dind：

• Docker Access：true
• Docker Socket：留空——不挂载任何 socket
• Worker Docker Daemon Host：tcp://${PRIVATE_IP}:3376
• Worker Docker TLS Verify：enabled
• Worker Docker Certificate Path：/etc/docker/dind/certs/client（worker 节点上的路径，只读挂进每个 worker 容器）

其余字段：Network Admintrue；Docker Networkpentagi-network；Public IP Address${PRIVATE_IP}；Work Directory 留空（用 Docker 卷）；Default Imagedebian:latest或留空；Pentesting Imagevxcontrol/kali-linux或留空。

两组证书路径不可互换：host 证书解析于主节点，dind 证书解析于 worker 节点。特别要注意文档的红字警告——绝不要把 Worker Docker Certificate Path 指向/etc/docker/certs/client，那是 host 守护进程的客户端证书，交给 agent 等于交出:2376的 host Docker API，隔离模型整体失效。

如果不用 installer 而是手工配置主节点.env，等价内容为：

## How PentAGI reaches the worker node's host Docker DOCKER_HOST=tcp://${PRIVATE_IP}:2376 DOCKER_TLS_VERIFY=1 PENTAGI_DOCKER_CERT_PATH=/opt/pentagi/docker-host-ssl # path on the MAIN node ## How worker containers reach dind DOCKER_INSIDE=true DOCKER_SOCKET= # empty: mount no socket DOCKER_INSIDE_HOST=tcp://${PRIVATE_IP}:3376 DOCKER_INSIDE_TLS_VERIFY=1 DOCKER_INSIDE_CERT_PATH=/etc/docker/dind/certs/client # path on the WORKER node DOCKER_NET_ADMIN=true DOCKER_NETWORK=pentagi-network DOCKER_PUBLIC_IP=${PRIVATE_IP}

PentAGI 会把DOCKER_INSIDE_*三个变量去掉_INSIDE_段后注入 worker 容器（即DOCKER_HOST、DOCKER_TLS_VERIFY、DOCKER_CERT_PATH），并把证书目录以相同路径只读挂载进去，容器内docker直接可用。

端到端验证

在有一个真实 worker 容器运行后，从 worker 节点验证：

docker-host-tls exec -it pentagi-terminal-1 docker version # talks to dind, not the host docker-host-tls exec -it pentagi-terminal-1 env | grep DOCKER_

第二条命令应显示DOCKER_HOST、DOCKER_TLS_VERIFY、DOCKER_CERT_PATH（名称中不含_INSIDE_），并且容器内不存在/var/run/docker.sock。

防火墙端口规划

worker 节点需要放行的端口如下（前两个只允许主 PentAGI 节点访问，因为嵌套容器可用--network host探测本节点所有端口）：

端口	绑定地址	服务
2376	${PRIVATE_IP}	Host Docker API（TLS）
3376	${PRIVATE_IP}	dind API（TLS）
9323	${METRICS_IP}	Host Docker 指标
9324	${METRICS_IP}	dind 指标
8080 / 9100	${METRICS_IP}	cAdvisor / node-exporter（可选部署）
9443	${PRIVATE_IP}	Browser 抓取服务（可选部署，Basic Auth 保护）
28000–30000	全部接口	每个 worker 容器动态分配 2 个端口，供 OOB 攻击技术回调，需允许被测试的目标网络访问

默认METRICS_IP=127.0.0.1时指标端口无需对外开放；改成${PRIVATE_IP}后需额外放行 9323、9324、8080、9100 并仅对抓取主机开放。cAdvisor 挂载docker.sock，把8080暴露给抓取主机之外的任何客户端，相当于给出与 host Docker 同级的访问权。

故障排查

docker logs docker-dind # dind daemon output docker-dind-sock info | grep -A 20 "Security" # confirm seccomp profile is active docker-dind-sock plugin ls # confirm authz plugin is enabled # Re-bootstrap the plugin from scratch sudo rm -f /var/lib/docker-dind/.authz-plugin-installed \ /var/lib/docker-dind/.authz-policy-hash sudo docker rm -f docker-dind && sudo run-dind

• run-dind报缺少/dev/fuse时，先sudo modprobe fuse再启动。
• 插件状态异常时按上面最后一组命令删除标记文件并重新引导（注意前两条rm只删除/var/lib/docker-dind下的两个标记文件，会触发重新下载安装插件）。
• 策略变更后旧容器仍带旧权限的问题，由上文"策略更新"小节的 purge 机制处理，不要手动只重启 dind。

最后保留一个文档明确给出的边界认知：authz.rego是一份拒绝列表，"它的强度只取决于其完备性"——任何能授予 SYS_ADMIN、设备访问、命名空间逃逸或文件系统访问的新 Docker API 字段都必须补充进去；如果要求内核级强制保证，文档指向 dind-rootless。完成上述四步并让dind-policy-tests全绿、worker 容器内验证通过后，这套 worker 节点即可按 Standard 模式接入主节点的 PentAGI；worker 节点上的浏览器抓取服务与指标 exporter 属于独立可选部署，指南在同一文档中给出了对应步骤，可按需另行实施。

【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi