Hi there,
I am working in an infrastructure where security a major concern. Currently, I am setting up a (single node) swarm cluster, but I guess my question is not only related to swarm.
Of course, we all trust our containers, but sometimes you may use a foreign container or you are just afraid of any security issues, so here is my topic:
I am using Traefik as a reverse proxy to offer different services of the docker (swarm) host.
Traefik itself is deployed based on a template from dockerswarm.rocks with some modifications. Host ports are used (I can also provide the compose file, but I have to delete some internal stuff first).
For every service/container an internal overlay network is created. In this network, the container itself and Traefik are included so that Traefik can forward traffic to the container.
But also the container has access to Traefik now. It can access all defined endpoints. So that gives me a bad feeling because, with some modifications to the containers host file, it would be possible to access a different service served by Traefik. Is it somehow possible to restrict this access? Am I missing something obvious? For now, I configured a whitelist middleware, which is okay but would not work that easy in all circumstances (maybe a blacklist would be easier to maintain).
Is it possible to bind Traefik's endpoints dynamically on selected docker networks? I guess that is pretty much the same question as asked on Stackoverflow.
Thanks for your support 
Best
Chris
Hi @culpinnis
Thank you for your interest in Traefik Proxy.
From what I understood you would like to control traffic flow between your applications. On Swarm, any container can access each other through the host network if it's attached to it and you know the target IP.
It is not the role of load balancer / reverse proxy to filter the traffic flow between running containers. This is the role of the cluster orchestration tool.
I would try to read what is Network Policy in the context of Kubernetes because I think this is what you might be looking for.
Let us know, Thank you
Hi,
thanks for your kind answer and sorry about my delay to reply.
The containers are using overlay networks with the internal flag. That means they can only connect to other containers located in the same overlay network (at least that's how I understood it - maybe I am wrong: docker network create | Docker Documentation). I know the Network Policy features of Kubernetes and you are right, I am looking for something similar in Swarm. So what I have done is to make internal overlay networks just including the container that should be proxied by traefik and the traefik container itself. In that way, traefik can connect to the target container, but the target container can also connect to traefik.
That's a solution working fine for me and I have read about this kind of configuration in different tutorials.
The only thing that is not perfect in this solution is that the target container can also connect to the traefik container which is listening on all configured endpoints on this interface. Of course, a possible attacker would need to archive several things to get a connection to another container:
- Find a security issue in the proxied container application
- Modifying the host file to match a configured router in traefik to connect to another container.
From my understanding, this issue could be solved when traefik would just listen to selected docker network interfaces. Maybe there is another option I am missing, maybe an IPTABLE configuration for each of those networks?
My current workaround is to define a whitelist middleware and of course an authentication middleware for endangered services.
I agree that the orchestration tool should be capable of restricting such connections, but I haven't found any feature that would me allow to do this - and I guess the option to just listen on selected docker networks would be a(n) (additional) security feature of traefik? Is it possible to configure traefik to listen to a selected docker network interface?
I hope I was able to describe the problem accordingly. Thank you!
ps.
Of course, I could use Kubernetes, but that is a completely different topic 