You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(docker): separate iptables setup into init container (#1281)
* feat(security): separate iptables setup into init container
Add awf-iptables-init service that shares the agent's network namespace
via network_mode: "service:agent" and runs setup-iptables.sh before
signaling readiness. The agent container never receives NET_ADMIN
capability, eliminating the startup window where privileged capabilities
were held.
Key changes:
- Add iptables-init service to docker-compose with NET_ADMIN + cap_drop ALL
- Remove NET_ADMIN from agent container's cap_add
- Agent entrypoint waits for /tmp/awf-init/ready signal (30s timeout)
- Init container uses same image as agent, exits after iptables setup
- Update cleanup scripts to handle awf-iptables-init container
Fixes#375
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: add agent healthcheck to prevent init container race condition
The iptables-init container uses network_mode: service:agent to share the
agent's network namespace. With depends_on: service_started, Docker may try
to look up the agent's PID in /proc before it's fully visible, causing
"lstat /proc/PID/ns/net: no such file or directory". Adding a healthcheck
to the agent and using service_healthy ensures the PID is stable before
the init container starts.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: pre-build Docker images in Test Examples CI
The init container architecture requires the agent image to have the
updated entrypoint that waits for the init container's ready signal.
Without pre-building, examples use GHCR images with the old entrypoint,
causing the agent to exit because it tries to run setup-iptables.sh
without NET_ADMIN capability.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: pass SQUID_PROXY_HOST/PORT to init container for DNS resolution
setup-iptables.sh reads SQUID_PROXY_HOST (not AWF_SQUID_HOST), but the
init container only passed AWF_SQUID_HOST. Since the init container uses
network_mode: service:agent, it may not have DNS resolution for compose
service names, causing getent hosts to fail and the script to exit before
writing the ready signal. Use the direct IP address to avoid DNS issues.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: skip DNS reverse lookup when SQUID_HOST is already an IP address
The init container passes SQUID_PROXY_HOST as a direct IP (172.30.0.10)
to bypass DNS resolution. But setup-iptables.sh runs getent hosts on it,
which does a reverse DNS lookup that fails in Docker containers, causing
the init container to exit before writing the ready signal. The agent
then times out after 30s waiting for /tmp/awf-init/ready.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: add NET_RAW capability to init container and improve diagnostics
The iptables init container was hanging because cap_drop: ALL removed
NET_RAW which iptables needs for netfilter socket operations. Also
removed no-new-privileges which can block iptables binary execution.
Added diagnostic output logging: setup-iptables.sh output is written
to /tmp/awf-init/output.log (shared volume), and on timeout the
entrypoint displays the log for easier CI debugging.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: override init container entrypoint to prevent deadlock
The init container uses the same Docker image as the agent, which has
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]. The entrypoint.sh contains
an "init container wait" loop that waits for /tmp/awf-init/ready to
appear. When the init container runs through this same entrypoint, it
deadlocks waiting for itself to signal readiness.
Fix: Set entrypoint: ['/bin/bash'] on the init container to bypass
entrypoint.sh and run setup-iptables.sh directly.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: set AWF_API_PROXY_IP before init container definition
The init container's environment object captures values at definition
time (JavaScript object literal evaluation). AWF_API_PROXY_IP was set
on line 1196 (inside the enableApiProxy block) but read on line 1076
(init container definition), so the init container always got an empty
string. This caused setup-iptables.sh to skip adding ACCEPT rules for
the API proxy IP (172.30.0.30), blocking agent→api-proxy connectivity
and failing the API proxy health check.
Move the assignment before the init container definition so the value
is available when the object literal is evaluated.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
0 commit comments