The default capability set granted to containers does not allow a container to modify network settings. By running in privileged mode, you grant all capabilities to the container -- but there is also an option to grant individual capabilities as needed. In this case, the one you require is called CAP_NET_ADMIN (full list here: http://man7.org/linux/man-pages/man7/capabilities.7.html), so you could add --cap-add NET_ADMIN
to your docker run command.
Make sure to use that option when starting both containers, since they both require some network adjustments to enable transparent packet interception.
In the "proxy" container, configure the iptables pre-routing NAT rule according to the mitmproxy
transparent mode instructions, then start mitmproxy
(with the -T
flag to enable transparent mode). I use a small start script as the proxy image's entry point for this since network settings changes occur at container runtime only and cannot be specified in a Dockerfile or otherwise persisted.
In the "client" container, just use ip route
commands to change the default gateway to the proxy container's IP address on the docker bridge. If this is a setup you'll be repeating regularly, consider using an entry point script on the client image that will set this up for you automatically when the container starts. Container linking makes that easier: you can start the proxy container, and link it when starting the client container. Then the client entry point script has access to the proxy container's IP via an environment variable.
By the way, if you can get away with using mitmproxy in non-transparent mode (configure the client explicitly to use an HTTP proxy), I'd highly recommend it. It's much less of a headache to set up.
Good luck, have fun!