With this setup, we expect direct network connections from subject to fail, unless the go via the proxy container. The proxy container is connected to both intnet and extnet, so it can both access other containers in the intnet as well as access the wider Internet. The subject container is only connected to intnet, so it can only connect to other containers that are also connected to intnet. We define two networks: an internal network named intnet and an external network named extnet. This is the same as the previous one, except for networks configurations. So, this is our initial version of the sandbox: If you haven’t been spoilt by it, I encourage you to check it out. This is an excellent proxy application, best used for intercepting requests during development.
Specifically, we will use the web interface version called mitmweb. Not very useful.įor the proxy container, we’ll use mitmproxy. Without this, the container would start, do nothing, and just exit. This makes the container stay running so that we can get in and play around. The proxy container, which runs an HTTP proxy.įor the subject container, we’ll use an ordinary, friendly, memorable, vanilla Ubuntu container with the command set to sleep infinity.The subject container, which is expected to make all outgoing requests via the proxy only.Let’s start with two containers, in a docker-compose.yml configuration. We want to ensure that outgoing requests made from the subject application always fail unless they go via the proxy. We need a sandbox environment where there’s a proxy and a subject application. With explicit configuration, we can also have an internal network where connections are only allowed to other containers that are also connected to this internal network.ĭocker’s official documentation about networking in Docker Compose talks more in detail about this.
It provides a simple set of primitives to solve what we need here.īy default, Docker sets up a bridge network for us that allows connectivity to external endpoints. We’ll be using Docker’s networking features. This article is my attempt at answering this. But if we don’t have a network that blocks non-proxy traffic, how do we test this? How can we ensure that when a proxy is configured, all outgoing requests are only ever made through the proxy? Now several applications, web application servers included, support the HTTP_PROXY and HTTPS_PROXY environment variables to configure such a proxy. For a self-hosted web application, the server will also need to make any and all outgoing connections via this proxy. Any network traffic that tries to go out bypassing this proxy will be blocked. Several network configurations, especially in large companies and universities, have a proxy configured for all outgoing traffic. See more from Shrikanth on his personal blog
0 kommentar(er)
