How to connect the containers?

[YourDeveloperFriend]

I'm having a bit of trouble wrapping my mind around connecting two containers. I think the easiest way is to make each container host their own server of some sort (probably sockets). They would all listen on some kind of "main" port, and will also be aware of the ports of those they can interact with. So, essentially, in our example:

The webfront listens on their main port which should be configured by the owner to connect with port 80. The webfront is also aware of two ports, one for the Project and one for the DataStore.
The Project only listens to the main port, and is not aware of anything else.
The Transformer only listens on its main port, and is not aware of anything else.
The DataStore listens on its main port, and is aware of the port for the transformer.

This seems like the best way to handle communication. However, there is the issue of protection. For example, DataStore has two openings, getAll and save. If we wanted to limit webfront so that it could only call getAll and not save. So we could restrict the access on the port level or in the code level:

Port level restriction:
assign getAll and save each their own port. That way, webfront is only aware of the one port.
Problem: A service may have anywhere up to 50-100 methods and will have to run 50-100 servers, which may or may not be a big deal.

Code level:
The socket server on DataStore checks the permissions of the sender (webfront) and decides not to accept any "send" events.
Problem: This puts the security issue directly into the hands of DataStore. Granted, they'll want to be secure, but if they screwed up (or purposefully put in a backdoor), there would be a security hole.

[jayhendren]

Nathan,

I apologize if this e-mail is a bit perfunctory, but I need to write and send this off quickly -

I think you’re overcomplicating and overthinking things.

Call the host running the docker service and all of the docker containers the “docker server”. Essentially, especially in terms of networking, you should think of each container on the docker server as an individual host (or server, computer, machine or whatever makes the most sense). That means that each container has its own IP address on a private network that’s internal to the docker server, each container has its own set of ports to listen on for TCP/UDP connections, etc.

To communicate between servers, a container must be listening on a port. This port is a port on the container itself, not on the docker server. When a container is listening on a port, it can accept incoming connections from any other container on the docker server, but it does not expose any services on any ports on the docker server unless we explicitly allow it by mapping a port on the docker server to a port on a container. Furthermore, because the internal, private docker container network is controlled by docker, we can allow even more secure methods of communicating between containers. This is done by “linking” containers. Essentially, this means that docker will only allow predefined connections between containers. This is basically the same as punching a hole in a firewall to allow connections between two hosts on a predefined port.

Hopefully that makes sense - just think of the containers as hosts on a private network and think of docker as controlling a firewall on that private network and it should all make sense.

This just means that any cell will need to mention in its configuration what ports it is listening on, and docker can take care of the rest.

• Jay

On Feb 20, 2014, at 6:20 PM, Nathan Tate notifications@github.com wrote:

I'm having a bit of trouble wrapping my mind around connecting two containers. I think the easiest way is to make each container host their own server of some sort (probably sockets). They would all listen on some kind of "main" port, and will also be aware of the ports of those they can interact with. So, essentially, in our example:

The webfront listens on their main port which should be configured by the owner to connect with port 80. The webfront is also aware of two ports, one for the Project and one for the DataStore.
The Project only listens to the main port, and is not aware of anything else.
The Transformer only listens on its main port, and is not aware of anything else.
The DataStore listens on its main port, and is aware of the port for the transformer.

This seems like the best way to handle communication. However, there is the issue of protection. For example, DataStore has two openings, getAll and save. If we wanted to limit webfront so that it could only call getAll and not save. So we could restrict the access on the port level or in the code level:

Port level restriction:
assign getAll and save each their own port. That way, webfront is only aware of the one port.
Problem: A service may have anywhere up to 50-100 methods and will have to run 50-100 servers, which may or may not be a big deal.

Code level:
The socket server on DataStore checks the permissions of the sender (webfront) and decides not to accept any "send" events.
Problem: This puts the security issue directly into the hands of DataStore. Granted, they'll want to be secure, but if they screwed up (or purposefully put in a backdoor), there would be a security hole.

—
Reply to this email directly or view it on GitHub.

[YourDeveloperFriend]

That's kind of how I saw it. We may need to have this conversation in person, because I still don't see how that addresses the problem. Are you saying that it doesn't matter if one container is listening on twenty different ports depending on the method or "event" is being called? Do you see what I mean?

So if we have our dataStore listening on just one port, and we push all events through that port, then we would have to write in our code some way to limit or filter any unauthorized requests. So if webfront is only allowed to call getAll, and not save, then on the dataStore server, there would have to be code that says something like:

if not isAuthorized(request.host, request.event) then return new Error('UnauthorizedRequest')

Or we could just have dataStore listen on two different ports, one for save and one for getAll, and make webfront aware of one of them only. This limits the chance of mistake on dataStore's part, but increases the number of ports that dataStore has to listen to, thus effectively having to run 20-50 servers for each operation permitted.

Does that make sense? We can discuss this more on Monday.