-
Notifications
You must be signed in to change notification settings - Fork 163
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
Security problem with mounted docker.sock? #20
Comments
I'm not a security expert. But this is what I think: I don't think it is a security issue. Of course you should avoid mounting docker.sock to other containers. Only mount it on containers you trust and know it needs connection to docker. Like this project, that completely relies on docker host. Currently we have 2 docker image variants, from alpine and from scratch. The scratch image not even have a shell installed, I recommend using that one if you're concerned about security. I also want to mention that although mounting docker.sock is the most convenient way to run it, there are alternatives. If your container is capable of accessing the docker host by IP, you could use the connection environment variables (DOCKER_HOST...) to setup a connection. And last, can you please explain a bit further your suggestion? Do you wan't to separate the caddyfile generation logic, from the caddy web server? So, one container would generate the caddyfile, and multiple others would use that caddyfile to serve http trafic? |
Hi @lucaslorentz and thanks for quick reply. Separate cadddyfile generation logic (with access to docker.sock) from the reverse proxy / caddy (serve http traffic) should be more secure I think. But from scratch without installed shell / linux root filesystem should be fine! So I just have to change the tag from alpine to scratch? I'll try it. |
Actually, just remove https://hub.docker.com/r/lucaslorentz/caddy-docker-proxy/tags/ |
Scratch image seems to be a secure option for you. |
I still have headaches with the docker socket mounted into the Caddy container. Also this means containers can only run on manager nodes (swarm), right? This is somewhat a limitation if you need to use replication mode |
Okay at least figured out we could use Docker API |
@deeky666 I just faced the issue where i need to inspect the real client IP. And I switched to global replication and host port binding. But I still use a criteria to run only on manager nodes and I only load balance traffic through manager nodes. So, lately I've been thinking about how to split the file generation. It would be nice to use this project to generate the caddyfile and @abiosoft caddy docker image to run caddy. His image is well maintained and much easier to build and add plugins. The option I prefer, is to generate a caddyfile into a Swarm Config, and map the Swarm Config into caddy containers. But I could also add an option to generate into a file. Everytime the generator updates the config it could trigger a service update --force, to update all caddy containers. I believe that way it would even respect the update_config in the service: parallelism and delay. |
Would be nice to split dockerfile generation from the caddy to run it. |
@lucaslorentz that proposal sounds ok. |
Another solution is to have a container on the manager nodes that mounts the docker socket and then exposes it via tcp. I've seen this project being used: https://github.com/Tecnativa/docker-socket-proxy Then you'll have caddy-docker-proxy on the worker nodes listening to the socket proxy container for events on a separate network. the socket proxy only exposes read-only events and would not be accessible to the outside. can caddy-docker-proxy use a tcp endpoint for DOCKER_HOST? |
@mxrlkn If the objective is just to have read-only events, just specifying the socket as ro sould be enough ? |
I'm not sure, but I think that isn't enough. The socket file would be read only, but socket would be usable? |
@Dorsug :ro only means that the socket file is read-only. all events will still go through. |
I just tested it with https://github.com/Tecnativa/docker-socket-proxy and it works fine. Here's my compose file:
I needed to allow a few more api paths for caddy-docker-proxy to work. It's a lot better, but a custom proxy for what this project specifically needs would be more secure. |
I just want to point out that using |
Because docker.sock ist mountet to the caddy reverse proxy it could be a security issue? What do you think about? Would it possible to split it up in a caddy reverse proxy and a second container with a shared caddyfile / caddy config?
The text was updated successfully, but these errors were encountered: