问如果容器被破坏了，这是否意味着主机也被破坏了呢？

EN

如果内核在容器中被破坏，主机就会被破坏.

表面上，受损的容器不应该对主机造成伤害。然而，容器安全性不是很好，而且通常存在许多允许特权容器用户危害主机的漏洞。这样，容器通常不像完整的虚拟机那么安全。这并不意味着虚拟机不能被黑。他们只是没有那么糟糕。

如果在虚拟机中利用内核，攻击者仍然需要在虚拟机管理程序中找到一个bug。如果在容器中利用内核，整个系统(包括主机)就会受到破坏。这意味着当使用容器时，内核安全bug作为一个类要严重得多。

容器通常通过使用命名空间实现：

命名空间将全局系统资源包装在抽象中，使进程在名称空间中看起来它们拥有自己的全局资源的独立实例。对全局资源的更改对于作为命名空间成员的其他进程是可见的，但对其他进程是不可见的。

不幸的是，Linux名称空间通常会从内核暴露更大的攻击表面积。名称空间中的许多 内核 脆弱性 是 可开发。虽然并不是每个容器解决方案都使用Linux名称空间，但它们都使用了与同样的安全问题相同的技术。有些容器，如Docker，能够使用名为seccomp的syscall过滤框架来减少内核的攻击表面积。这是一个改进，但还不够。

如果您不使用容器，并且不需要(非特权)用户名称空间，则可以通过设置使它们失效来提高安全性，从而选择user.max_user_namespaces = 0。

来自丹尼尔·夏皮拉：

对于容器化环境来说，...内核的利用可能是毁灭性的。这是因为容器与主机共享相同的内核，因此仅信任内置的保护机制是不够的。

因为容器没有VM那么孤立，是的，在某种程度上它们不太安全。见福林的答案。

尽管如此，我认为值得注意的是，从应用程序安全性的角度来看，容器也提供了一些好处。例如，由于它们通常运行单个进程，因此限制了攻击面，因此容器中没有运行cron监视器或ssh守护进程。容器映像是不可变的:在重新启动时，它们从原始二进制文件中加载。您不能覆盖应用程序。大多数集装箱技术还允许对哪些港口开放和向谁开放进行精确控制。您可以拥有一个用于DB的容器，该容器不能从其他容器以外的任何地方访问。

所有这一切都假定这些特性如广告所示，当然没有缺陷。如果攻击者设法逃离容器，上述任何一个都不适用。它增加了一些开销，但皮带和吊带的方法是可能的:容器上的VM。