Multi-Platform Docker Internal Network Connect From Host

Viewed 198

I have a unique Docker issue. I am developing an application which needs to connect to multiple Docker containers. The gist is, that this application will use the Docker SDK to spin up containers and connect to them as needed.

However, due to the nature of the application, we should assume that each one of these containers is compromised and unsafe. Therefore, I need to separate them from the host network (so they cannot access my devices and the WAN). I still have the constraint of needing to connect to them from my application.

It is a well-known problem that the macOS networking stack doesn't support connecting to a docker network. Normally, I'd get around this by exposing a port I need. However, this is not possible with my application, as I am using internal networks with Docker.

I'd like to accomplish something like the following. Imagine Container 2 and Container 3 are on their own private internal network. The host (which isn't a container) is controlling the Docker SDK and can query their internal IPs. Thus, it can easily connect to these machines without this network being exposed to the network of the host. Fortunately, this sort of setup works on Linux. However, I'd like to come up with a cross platform solution that works on macOS.

Network diagram

1 Answers

I had a similar situation. What I ended up doing was:

  • The app manages a dynamic container-to-port mapping (just a hash table).
  • When my app (on the host) wants to launch a container, it finds an unused port in a pre-defined range (e.g. 28000-29000).
  • Once it has a port, it maps the container's port to some port in a pre-determined range (e.g. -p 28003:80).
  • When my app needs to refer to a container, it uses localhost:<port> (e.g. localhost:28001).

It turns out to not be a lot of code, but if you go that route, make sure you encapsulate the way you refer to containers (i.e. don't hard-code the hostname and port, use a class that generates the string).

All that said, you should really do some testing with a VM deployment option before you rule it out as too slow.

Related