Accept traffics to the reverse proxy

[snwnde]

Per the current principal of operation, traffics within the subnet are dropped unless they are already established or from the whitelisted containers (most likely just the reverse proxy container).

However, there are legitimate cases for containers to initiate connection to the reverse proxy as well. For example, an SSO integration would need to have access to the auth service via the reverse proxy.

With the current implementation, one can either 1. add the containers to the whitelist or 2. turn on ALLOW_HOST_TRAFFIC and make the connection via host port, but both would have a larger attack surface than allowing some containers to initiate the connection to the reverse proxy within the subnet.

[kaysond]

Is there a reason your auth service isn't available directly? Meaning why not create an additional network containing your SSO client service and the auth service? Even if you could do what you're asking, you'd not only be granting access to the auth service, but everything behind the reverse proxy. That's also an increase in attack surface.

In any case, the current implementation doesn't really make this practical (allowing specific access for specific containers). I am slowly working on a rewrite that would make this much easier, though.

[snwnde]

Is there a reason your auth service isn't available directly? Meaning why not create an additional network containing your SSO client service and the auth service?

Well doing that is almost like to have each service on a unique network, which I think is the problem that trafficjam is trying to solve?

Even if you could do what you're asking, you'd not only be granting access to the auth service, but everything behind the reverse proxy. That's also an increase in attack surface.

That is true only if the reverse proxy itself it behind another reverse proxy? Otherwise the reverse proxy is already accessible from outside.

In any case, the current implementation doesn't really make this practical (allowing specific access for specific containers). I am slowly working on a rewrite that would make this much easier, though.

Glad to hear that!

[kaysond]

Well doing that is almost like to have each service on a unique network, which I think is the problem that trafficjam is trying to solve?

...good point. If all your services need SSO then it would defeat the purpose.

That is true only if the reverse proxy itself it behind another reverse proxy? Otherwise the reverse proxy is already accessible from outside.

What I mean is if your client service connects to the auth service container directly, it can't initiate communication anywhere else. But if it can initiate communication to your reverse proxy, it can then initiate communication to any service just by sending the right request to the reverse proxy. You're right that in a sense it's no different than a public user accessing the reverse proxy, but I think having full network access to the reverse proxy container network is still a bigger attack surface. Come to think of it, I should probably support specific ports in the firewall entries...

---

After the rewrite, I think the best approach might be to have two networks: one where only the reverse proxy can initiate communication, so it can forward requests to backend service containers, and another for auth, where all containers can initiate communication to the auth container but nowhere else

Might cause issues with redirects though. Anyways. Hopefully I can get the rewrite done soon.

[NorskNoobing]

all containers can initiate communication to the auth container but nowhere else

I think that this would be great in my use-case too, where I have multiple services that need connection to a DB, but not eachother. What I'm thinking is exactly how the auth server example would work. This is essentially whitelisting destination instead of source, like how the image currently works. For now I'll probably have to use one network per service.

[jesusfer]

I have a very similar use case like @NorskNoobing apart from the one trafficjam solves. Did you find a solution other than one network per service?

[NorskNoobing]

Currently I'm just using one network per service connection, which works fine if you change the docker default network size. However, I want to migrate over to Kubernetes and use its NetworkPolicy stuff, which I think would look cleaner.

[kaysond]

The rewrite is in progress! Unfortunately progress has been slow...