问从Docker容器代理web应用程序是一个很好的实践吗？

EN

这种模式有什么缺点吗？

我没有看到任何直接的缺点，除了开销和磁盘空间的使用，如果您部署您的应用程序在滚动的基础上，而不保持卷在检查。请记住，“删除容器后，Docker数据卷仍然存在。”见码头文档。

然而，可能有一些长期的缺点。例如:由于您在生产中运行此操作，您多久对容器应用安全更新？考虑到码头映像是从上游移除的一步，安全补丁可能部署得不够快。您多久检查一次容器的更新，并重新部署它们？

另外，如果您的一个容器被关闭，您会过滤出站连接吗？如果应用程序中的一个小漏洞使其成为僵尸网络的一部分，该怎么办？

怎么才能更安全呢？

那得看情况。您在任何容器中挂载主机的/proc或/sys吗？如果是这样的话，请注意这类攻击 (并搜索“码头逃逸”以获得有趣的阅读)

应用程序容器对攻击的暴露程度如何？

对于来自网络边界之外的攻击，它们暴露得就像应用程序在系统上作为常规UNIX进程运行一样。

奇怪的是，对于来自其他容器的攻击，您实际上是在增加攻击面:假设一些容器可以看到其他容器(例如，web服务器可以看到db服务器，或者日志服务器，等等)，那么您必须确保每个容器不运行额外的服务，最重要的是保持它们的最新。

码头工人有什么安全考虑吗？

是的但是这个问题太宽泛了。由于集装箱管理不善(例如安装/proc)，码头出轨。有潜在的码头利用。偶尔会有一个允许本地用户攻击它的错位。如果你在寻找一颗能让你忘却的银弹，你会失望的.

在web/appserver前面运行一个轻量级代理是个好主意，虽然我是apache的忠实粉丝，但我认为作为代理，它是一个糟糕的选择；它远非轻量级的，因此您的体系结构将无法处理高流量的问题。我会推荐nginx或ATS或可能的清漆。但是还没有ATS或modsecurity的清漆端口，而且nginx版本也没有apache模块那么稳定。所有这三个方面都有备选的WAF --它们是否适合您，取决于您对WAF所做的操作。

正如洛伦佐所说，码头的图像往往滞后于释放补丁。您没有提到如何解决服务器的配置、部署和修补问题。

您的所有守护进程都应该以非特权用户的身份运行，而linux发行版上的所有标准应用程序都是以非根用户的身份运行，但大多数守护进程将以root的形式开始运行，以获取一个低编号的端口。您可以在高编号端口上以非根用户身份启动它，并使用iptables进行端口转换，或者使用linux能力委托权限绑定低编号端口或在其他地方进行端口映射。但请注意，这可能涉及修改配置文件，这可能会导致与发行版补丁的冲突。

您的设置充分隔离了不同的环境，使一个容器中的漏洞无法访问另一个容器。

您应该检查的一件事是，web应用程序没有以根用户身份在docker容器中运行。web应用程序代码应该以正常用户的身份运行。