-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mounting docker socket, security concern ? #5
Comments
+1 I think it makes sense to seperate the Nginx and the Dockergen . |
As a demo I quickly prototype what I had in mind: Would it make sense in nginx-proxy context ? |
Some good idea here. I think separating them would work fine. docker-gen could generate files to a shared volume and not need to restart anything directly. That would make it work with your inotify/linked volumes idea. I'm inclined to keep nginx-proxy as a single container for now as it makes things simpler as things are evolving with it. I don't think it would be too difficult to separate them out into two containers at some point though. |
docker-gen 0.3.4 has a new feature that should make running nginx and docker-gen in separate containers easier. There is a new |
If I understand correctly, to get the two different containers working, you'd started up a basic nginx container and then start up a docker-gen container that has access to the sites-enabled volume and the nginx container id passed as it would be great to have an official write up on how to get them both working in tandem. |
Yes, that's basically how it would work. You could name your nginx container "nginx" and use that instead of the actual container ID as well. I haven't had time to try it yet but when I do I'll add some documentation of how to set it up. |
Thanks atomaka. Close nginx-proxy#5
Hi,
docker-gen is great and nginx-proxy sounds promising.
But for the latter I've some questions about the security impact of mounting docker socket into the reverse proxy containers.
AFAIU, it means that if the reverse proxy container get compromised I would give attacker whole access to docker daemon (creating, deleting containers, etc). As the reverse proxy is the most exposed part of the infrastructure, it's the most likely to be attacked.
There is maybe an alternative to have a 3rd party container that would run docker-gen and generate configuration for the reverse proxy and have only the notify & reload stuff (maybe linked together with --volumes-from). What do you think ?
The text was updated successfully, but these errors were encountered: