feat(docker): trace an app in another container via a phantom sidecar#10
Merged
Conversation
…om sidecar Add --bind <ADDR> (default 127.0.0.1, unchanged behavior) so the MITM proxy can also listen on 0.0.0.0, making it reachable from other Docker containers on the same network. phantom itself never spawns the target process in this mode — a separately-managed app container is configured with HTTP_PROXY/HTTPS_PROXY pointing at the phantom sidecar service, the same "manual" pattern phantom already supported on a single host, now crossing a Docker network boundary. Applies to `phantom run` only; `phantom mcp` sessions keep binding loopback only. The MITM CA certificate is now written to <data_dir>/ca.pem on every `phantom run` (previously only ever written to a PID-scoped temp file, and only when phantom spawned a PHP child for curl.cainfo injection) so it can be bind-mounted into another container's trust store for HTTPS capture. Add examples/docker-sidecar/ with a runnable compose.yaml and a README covering the per-client/language CA-trust mechanics (there's no single env var every HTTP client honors) — explicitly flagged as unverified end-to-end in this environment (no Docker daemon available here); `docker compose config` confirmed the compose file's structure only. Rebuilt against the subcommand-based CLI restructuring (`phantom run`/ `list`/`get`/.../`mcp`) so this now targets src/cli.rs's RunArgs and src/commands/run.rs instead of the old flat main.rs. Scope: HTTP_PROXY-sidecar only, agreed with the user up front — transparent iptables/eBPF interception and cross-container ldpreload tracing are both out of scope, left as possible future work. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GbCUVmJxDEWtgJpE9drzga
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
--bind <ADDR>tophantom run(default127.0.0.1, unchanged behavior).--bind 0.0.0.0makes the MITM proxy reachable from other Docker containers on the same network, so phantom can trace an app it doesn't spawn — the target container just needsHTTP_PROXY/HTTPS_PROXYpointing at the phantom sidecar service. Same "manual" proxy-configuration mode phantom already supported on a single host, now crossing a Docker network boundary.phantom mcpsessions are unaffected — they keep binding loopback only.<data_dir>/ca.pemon everyphantom run(previously only ever written to a PID-scoped temp file, and only when phantom spawned a PHP child forcurl.cainfoinjection), so it can be bind-mounted into the target container's trust store for HTTPS capture.examples/docker-sidecar/with a runnablecompose.yamland a README covering the per-client/language CA-trust mechanics (there's no single env var every HTTP client honors).tests/proxy_bind_integration.rsverifying--bind 0.0.0.0still proxies correctly andca.pemgets exported.Scope: HTTP_PROXY-sidecar only. Transparent iptables/eBPF interception and cross-container
ldpreloadtracing are both out of scope — possible future work.Not verified end-to-end: no Docker daemon was available in the environment this was authored in, so
examples/docker-sidecar/compose.yamlwas only checked withdocker compose config(no daemon required). Please confirmdocker compose up --buildworks end-to-end before relying on it.Test plan
cargo fmt --all -- --checkcargo clippy --workspace --all-targets --all-features -- -D warningscargo build --workspace --all-targets --all-featurescargo test --workspace --all-targets --all-features(all green, including the newproxy_bind_integrationtest and the full pre-existing suite)docker compose up --buildinexamples/docker-sidecar/— needs a real Docker daemon, not verified here🤖 Generated with Claude Code
Generated by Claude Code