正如 p2k 所说，docker 不会帮助您解决 Wordpress 的问题。但是，如果您的意思是降低特权升级的风险，答案应该是肯定的，可能。

容器（LXC、openVZ、Solaris Zones 等）的主要特性之一就是：权限分离。Docker 只是不同容器（和 qemu，甚至 chroot！）上的通用框架。这样，您的基于 docker 的系统将永远不会比您为其选择的基础更安全。如果您使用 LXC（有或没有 docker），您将获得 LXC 实现的安全级别（这有点不完整，您必须使用 apparmor 或 SElinux 以确保安全）。

使用容器技术，您可以在门口阻止攻击者。但是你的门（wordpress）将被浪费。然而，恢复您的网站（容器）比整个受感染的机器要简单得多。

尽管如此，如果您在设计良好的 apparmor 设置下运行您的网络服务器和数据库服务器，并且您保持基本的安全规则（除非需要，否则在任何地方都没有写访问权限，经常打补丁，使用像 mod_security 这样的 WAF 等），无论如何您都可以达到不错的安全级别，而无需使用容器的开销。

我将分两部分回答这个问题，因为这里确实需要解决 IMO 的问题：使用容器系统和使用 Docker 作为容器系统。

使用容器系统

正如其他答案中提到的，单独使用容器系统不会为您提供更好的安全性。然而，使用容器系统将允许您采取行动，这些行动将被证明既容易又有效地检测到任何其他损害，从而使您能够快速和及早地采取行动。

• 安装tripwire 或类似工具：Tripwire（或OSSEC，也可以扫描日志文件以查找任何可疑活动等）之类的工具会创建一个数据库，其中包含文件系统中包含的各种文件的哈希值。这是为了让您能够检测到意外的文件更改，例如，当攻击者进入您的系统并开始替换您的 Wordpress 文件时。这些工具的弱点在于，成功获得适当权限的攻击者可能会更改数据库以隐藏其更改。

  容器的主要优点是来宾文件系统可以直接（而不是通过 VM 经常需要的一些软件中介）可供主机访问，而主机文件系统对来宾是不可访问的。这是在主机上运行像 Tripwire 这样的工具来监控来宾文件更改的理想情况：它将能够直接检测任何不寻常的更改，同时它自己的数据库将是安全的（攻击 Wordpress 服务器是一回事，它是另一件事是在来宾系统上提升权限，逃离容器，再次在主机系统上提升权限，以便最终能够访问 Tripwire 数据库）。

• 外部化您的日志：服务器将所有活动记录在所谓的日志文件中。在小型系统上，这些日志文件位于同一主机上，大部分位于/var/log目录中。这些文件是攻击者的直接目标，以隐藏系统危害（OSSEC早先提到会定期解析这些文件，并且可以发送警报电子邮件以在记录可疑活动的情况下发出警告）。

  虽然企业环境可以投资一台专用的独立机器来收集来自所有环境的日志，但容器提供了一种廉价的安全方式来设置syslog将日志存储在来宾环境之外，从而使攻击者更难以访问它们。

这些只是例子。事实上，容器在处理系统安全性方面为您提供了极大的灵活性。

使用 Docker 作为容器系统

作为第一个说明，越来越多的人不将 Docker 视为面向安全的容器，请参阅：

• Daniel Walsh领导RHEL Docker 支持团队的演讲并建议“假设在容器内运行的特权进程与在容器外运行的特权进程相同。 ”，
• 过去依赖 Docker 的CoreOS和Kagome等项目现在正在离开，
• 新项目被设置为像Sandstorm（或 CoreOS 的 Rocket，见上面的链接，但目前似乎处于非常早期的阶段）这样的 Docker 的安全替代品。

Docker 本身基于 LXC（有一些限制，见下文），您基本上可以选择使用 Docker 而不是 LXC 或使用成熟的独立 LXC（或使用替代解决方案，可能仍然依赖 LXC）。

无论您选择哪种解决方案，始终需要在功能和安全性之间进行权衡：功能越多，安全性就越低。

所以，如果你需要Docker 提供的功能，那很好，你可以去做。但是，如果您真的不需要它们，那么您可能会三思而后行，选择更轻的替代品。请注意，硬件虚拟化也会出现同样的困境，您必须在独立使用 Qemu/KVM 或在其上安装 Libvirt 之间做出选择。

只要您添加补充软件堆栈：

• 补充依赖项和功能可能需要您以比轻量级对应项更高的权限运行命令（LXC 和 Qemu 都设计为使用有限权限在最终用户帐户下运行，但是 Docker 和 Libvirt 需要以主机系统根用户身份运行用户）。如果发现安全漏洞，以如此高的权限运行代码可能会使情况变得更糟。
• 您必须面对使用更基本的安装不会遇到的限制和不兼容性。例如，为了提供真正的安全性，LXC 的最终版本 1.0 在一年半前提供了非特权容器。然而，Docker 仍然没有解决它的多个库不兼容问题，并且仍然无法利用这个特性，依赖于旧的、不太安全的 LXC 特性。
• 当您依赖一堆软件和库时，任何地方的问题都可能会阻止您的项目。您依赖的软件和库越少，您遇到阻塞问题的可能性就越小，解决问题就越容易（日志和分析的可能性越少，加上上面提到的不兼容性可能会使某个底层的变通方法工作可能会中断其他地方的东西），
• 最后，虽然技术问题可能会阻止您的项目，但它也可能导致安全漏洞。您使用的软件越少，您的攻击面就越小，也就是说，存在允许远程攻击者破坏您的环境的正确漏洞组合的可能性就越小。

因此，这不应阻止您使用 Docker 或构建任何其他类型的雄心勃勃的复杂项目。但是您仍然需要评估您将依赖的软件带来的功能。

我经常看到人们使用一个充满花里胡哨的迷宫系统，而他们实际上只知道一点点：这是妥协的大门。

我想知道，如果我将 Wordpress 放在一个 docker 中，这会是降低 Wordpress 漏洞利用风险的好方法吗？

不——如果你仍然有脆弱的顶层，为什么改变你的基础层会有所改善？

您可以在拆分数据和服务等方面应用几个概念……但那是另一回事。并且服务将再次没有变化（此处为 WordPress）。

同样，安全漏洞出现在 WordPress 中。因此，唯一的解决方案是更换应用程序或强化它。（定期/快速更新。删除（不必要的）插件。等等）