YannickB
commented
7 years ago That's a hard question, I already though many times about this topic.
At first, I wanted to explore the possibilities to have firewall for all expose ports at the Docker level, so we can control access to applications themselves. But I'm not sure this is possible if the firewall is in a container (or maybe with a privileged or pid=host container ?), and I really don't want to install a firewall in the node itself.
You suggest firewall in the proxy, I didn't though about that but I believe this is an excellent idea. This is the easiest way to control access to all web applications and Clouder is mostly designed toward them. But with this we will not be able to easily control access to non web application, for example we will not be able to restrict access to odoo-ssh containers per IPs.
The way I see it, we should have a firewall, in a container, with a web access so non-technical people can easily administer and grant access, which can control access to containers exposed ports, and url forwarded by the proxy. I do believe I'm asking too much...
lasley
Another nail in the security shield for us should be a Web Application Firewall.
I'm thinking something like ModSecurity built as a module & included into our proxy would be the best bet here.
Alternatively we could run the firewall as its own service, and proxy desired traffic through it.
Benefits of the former method is security by default, for everything. Downfall is that opt-out would be at the proxy image level, so you're either fully secure or fully insecure - no middle ground.
If we go the route of the secondary proxy, we would gain the benefit of opt-in/out security at the application level. The downfall of this method is that our network architecture will explode in terms of difficulty. We also still wouldn't be able to run secure & insecure on the same port - because the two proxy listeners would conflict.
Thoughts? Other techs/strategies?
cc @laslabs @YannickB