容器安全别只关注镜像漏洞！架构级风险才是重点。Linux内核共享是安全盲点，Namespace并非真隔离。轻量级VM、eBPF、System Call沙箱等技术重塑云原生安全，打造可观测、可控的信任边界。GitOps工作流保障安全态势，隔离是新的可扩展性？
译自：What We Wish We Knew About Container Security
作者：Duffie Cooley; Jed Salazar
几年前，如果你问我们容器安全是什么，我们会专注于软件供应链风险。我们会谈论恶意镜像、脆弱的依赖项和被入侵的注册表。这些威胁是真实存在的，但我们后来才明白，它们只代表了更大图景的一小部分。
更深层次的问题是架构性的。这不仅仅是关于容器内部的东西，还包括围绕它的边界。我们曾经认为命名空间、cgroup 和 seccomp 提供了强大的隔离。但我们逐渐意识到，这种信念是基于一种危险的误解。支撑容器运行时的 Linux 内核是一个共享的表面，信任它来提供租户之间的隔离，会造成严重的安全盲点。
本文探讨了我们通过惨痛教训学到的关于容器隔离的知识。我们想分享为什么这种洞察力很重要，因为当你不再假设边界是安全的那一刻，就是你开始设计真正安全的系统的那一刻。
Unix 的设计以优雅为目标。它给了我们像“一切皆文件”和“快速失败”这样的基本思想。但它不是为多租户工作负载而构建的。当然，它也不是为运行来自未知来源的恶意代码而构建的。
Linux 继承了这种血统。它最初是一个桌面操作系统，后来演变成现代云的支柱。但它仍然反映了它的根源。内核默认是允许的。它从未打算作为相互不信任的工作负载之间的强化边界。它的安全模型是随着时间的推移而改造的，而不是以隔离作为第一原则来设计的。
今天，Linux 内核的代码超过 4000 万行。每个容器都共享它。每个命名空间、cgroup 和安全模块最终都通过这个相同的单片层运行。将如此多的信任寄托在一个老化的基础上，风险很大。
容器之所以流行，是因为它们使打包、部署和扩展应用程序变得更容易。像 Kubernetes 这样的编排系统围绕这个抽象构建了一个完整的生态系统。但这种抽象是很薄弱的。容器不是一个单独的运行时；它们只是进程。
每个容器都映射到 Linux 中的一个进程 ID。分离的错觉是使用内核命名空间创建的。这些命名空间隐藏了像文件系统、网络接口和进程树这样的资源。但内核仍然是共享的。这个共享的内核变成了攻击面。如果发生容器逃逸，这个攻击面就会变成一个负担。
常见的攻击向量包括利用文件系统挂载、滥用符号链接或利用配置错误的权限。这些漏洞通常以主机本身为目标。一旦进入内核，攻击者就可以影响其他容器或支持它们的基础设施。这不仅仅是理论上的。容器逃逸确实会发生，而且一旦发生，该节点上的所有东西都会变得可疑。
限制进程可以看到什么和强制进程可以做什么之间存在关键的区别。命名空间做的是前者；真正的隔离做的是后者。
在 Linux 中，命名空间、cgroup 和 seccomp 过滤器协同工作，以创建包含的表象。但它们都运行在同一个内核之上。如果该内核受到威胁，这些边界就会崩溃。没有加密保证或硬件强制分离。
这导致了一些非常真实的后果：
- 单个受损的容器会影响主机上的所有其他内容。
- 漏洞修复通常意味着拆除整个集群。
- 许多团队在虚假的安全感下运作。
正如越来越流行的说法：容器并不包含。
在容器出现之前，我们使用虚拟机来隔离工作负载。每个虚拟机都有自己的内核。虚拟机监控器在工作负载之间创建了强大的边界，防止一个租户影响另一个租户。
虚拟机由于性能开销和启动时间慢而不再受欢迎。但许多这些缺点已经得到解决。例如，利用半虚拟化的项目现在提供了与容器相当的性能，同时恢复了强大的工作负载隔离。
半虚拟化修改了客户操作系统，使其能够高效地与虚拟机监控程序交互。它消除了模拟硬件的需求，从而减少了延迟并提高了资源利用率。一些开源项目已经探索了这个领域，表明在轻量级虚拟机中运行容器是可能的。这些系统保持了与 Kubernetes 的兼容性，并且只需要对应用程序工作流程进行最小的更改。
实际上，它们允许您在自己强化的区域中运行每个容器——甚至每个 Pod。这些区域消除了共享的内核状态，并减少了任何漏洞利用的影响范围。虽然存在一些开销，但它很小。在许多情况下，启动时间增加不到一秒。对于真正的隔离来说，这是一个很小的代价。
隔离不仅仅是在独立的环境中运行工作负载。它还包括了解他们在做什么，并且能够控制他们的行为。
这就是像 eBPF 这样的技术发挥作用的地方。eBPF 允许安全、沙箱化的程序在 Linux 内核中运行。这些程序可以观察系统调用、执行安全策略并发出日志，而无需用户空间代理。
构建在 eBPF 之上的工具，例如高级可观测性和运行时执行平台，允许团队实时监控和响应行为。它们不会阻止攻击者进入系统。但它们大大缩短了检测和响应所需的时间。
其他隔离技术包括系统调用沙箱、文件系统门控和最小权限强制执行。一些项目提供强化的容器运行时，集成了这些技术，使攻击者更难逃脱或提升权限。
总而言之，这些努力正在重塑容器安全真正含义的理念。它不再仅仅是关于镜像和漏洞；而是关于控制、可见性和信任边界。
我们正在进入云原生安全的新阶段。重点正在从检测转向预防，从监控转向执行。以下是一些正在出现的大趋势：
- 默认安全运行时正变得越来越实用。它们提供强化的边界，而无需开发人员更改构建应用程序的方式。
- 基础设施正变得越来越可组合。可观测性、网络和安全正在合并到一个单一的策略层中。
- GitOps 工作流程正在扩展到包括安全态势。安全性正在成为版本化、可审计的基础设施定义的一部分。
内核不再是最终边界。它现在是分层、可编程安全模型中的一个组件。
我们以速度和规模构建了云。现在我们意识到，没有安全保障的速度是我们无法承受的风险。容器改变了我们对部署的看法，但它们并没有解决隔离问题。在许多方面，它们掩盖了这个问题。
我们希望我们已经知道的是，安全不是从容器内部的代码开始和结束的。它始于它运行的环境——以及该环境如何很好地将其他一切排除在外。
容器安全的真正工作不仅仅是修补 CVE 或扫描注册表。它正在重新思考隔离的意义。
这里有一个大问题：在一个快速移动的工作负载、共享的基础设施和不断演变的威胁的世界中，隔离是新的可扩展性吗？它可能是分布式计算中我们仍然没有做对的最重要的原语。