问题描述
在实施了所有安全建议（如用户上下文为root，未挂载主机敏感卷，调整了权限等）的情况下，容器与虚拟机相比，在理论上至少存在哪些（更高的）漏洞风险？如果考虑网络接口，攻击者可以以何种不同方式入侵容器，相对于虚拟机而言？是否可能通过“恶意”TCP数据包迫使Docker守护程序以root权限创建容器？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
容器和虚拟机具有不同的抽象层级，因此存在不同的漏洞和保护机制。
在容器中，应用程序在共享的操作系统上运行，而在虚拟机中，操作系统在共享的硬件上运行。由于这些不同的抽象层级，导致了不同层次的漏洞和保护机制。
对于容器来说，如果成功地在内核级别执行攻击，可能会影响到共享的内核，从而突破容器的隔离。一些内核级别的攻击，如Meltdown和Spectre，就是典型例子。
虚拟机中的成功的驱动程序攻击可能会从虚拟机中突破出来，影响到运行虚拟机的虚拟化管理程序。虚拟机中的驱动程序攻击要比内核级别攻击要罕见得多，因此在这方面，虚拟机具有一定的优势。
还有一种方法是将容器运行时更改为在小型虚拟机中启动容器。像Kata Containers这样的项目正在研究这一点。这样，你可以在获取一些容器功能的同时，获得类似虚拟机的安全性。
容器相对于虚拟机具有巨大的优势。它们在一个最小化的环境中运行，拥有降低的权限、seccomp，以及可选的selinux/apparmor配置。你可以以无法在虚拟机中轻松实现的方式来锁定这个环境，例如只读文件系统，而且不包含攻击者可能需要来利用你的系统或者横向扩展攻击的工具，比如Shell、解释器和库文件。
因此，容器与虚拟机之间并没有明显的赢家。最佳答案可能是两者的结合，在自己的虚拟机上运行一些具有相似安全要求的容器。
用户的评论和问题：
1. 感谢您的回答！但如果一个容器内的单个二进制/库文件看起来容易受到内核级别攻击，这是否意味着所有使用Kubernetes的人都需要“接受”这个风险？（因为Kubernetes也使用容器）（不确定是否值得提一个单独的问题）
2. 我不确定是否理解了问题，因为Kubernetes可以根据需要将容器调度到不同的虚拟机上，以增加安全性。Kubernetes只是一个调度/编排工具，您需要在其下方进行组织并运行。我不太明白哪个容器内的二进制文件在容器中易受攻击，而在虚拟机中不易受攻击，通常情况下是反过来的，因为您可以在容器内对应用程序进行锁定，这在虚拟机中很难实现。请注意，以上解决方案中的内容是根据提供的问答数据和我的知识库生成的。由于版本差异和环境复杂性，建议在实际操作之前充分测试并考虑安全性。