AWS 推出 Nitro Sandboxes，在 EKS 上为每个 Pod 提供硬件级隔离

agentic AI、多租户 SaaS 和受监管工作负载，现在可以同时拥有专属 Amazon Elastic Compute Cloud（Amazon EC2）实例级别的隔离性和 Kubernetes pod 的简洁性。Nitro Sandboxes 为每个 pod 提供硬件强制的安全边界，其底层与隔离 EC2 实例之间所用的 Nitro System 相同。

Kubernetes 容器共享宿主操作系统。这正是它们快速轻量的原因，但也意味着一个容器中的漏洞可能危及同一台机器上的所有其他容器。典型的变通方案是为每个敏感工作负载分配一台专属机器。这确实有效，但成本高昂，因为机器大部分时间处于空闲状态，你是在用浪费的基础设施来换取安全。

以下几种趋势正使这种变通方案难以为继：

这些变通方案都依赖于持续为共享内核打补丁，并投入更多基础设施来隔离工作负载。更好的方法是采用一种架构，从根源上让一个工作负载的内核问题无法触及另一个工作负载，这样就不必在效率与隔离之间做取舍。自主 AI agent 现在能以机器速度探测、适应并串联漏洞利用，将每一个共享内核的弱点都变成攻击面，没有任何人类团队能足够快地修补。如果效率与安全之间的取舍不再必要呢？

今天我们推出面向 Amazon Elastic Kubernetes Service（Amazon EKS）的 AWS Nitro Sandboxes，借助它，pod 首次获得了强安全隔离。

每个沙箱化 pod 都运行在自己的轻量级虚拟机中，由与隔离所有 EC2 实例相同的 AWS Nitro System 提供支持。每个 pod 拥有自己的操作系统，与宿主及所有邻居完全分离。如果 pod 内部出现问题，任何系统调用都无法触及客户机内核之外的任何内容。任何需要强隔离的工作负载现在都能获得硬件边界，而无需为每个工作负载专门分配一台机器。

在 EKS Auto Mode 上，启用 Nitro Sandboxes 只需对 pod spec 做一行修改。你无需更改容器镜像、部署流水线或 Helm chart。你的 pod 仍然使用相同的 AWS Identity and Access Management（IAM）凭证（Amazon EKS Pod Identity）、相同的存储（Amazon Elastic Block Store 和 Amazon Elastic File System）、相同的监控（Amazon CloudWatch）、相同的网络（VPC CNI）以及相同的安全工具。kubectl exec、kubectl logs 和 kubectl port-forward 的工作方式完全相同。在标准 EKS 上，用户指南涵盖了如何为 Nitro Sandboxes 构建 AMI。

由于每个沙箱都运行完整的操作系统内核，应用程序的运行方式与标准容器中一样。AWS Nitro Sandboxes 通过了所有 Kubernetes 一致性测试。

你添加一行配置，pod 就获得了硬件安全边界。其他一切照旧。

Nitro Sandboxes 同时改变了两件事：pod 的隔离程度，以及它共享节点的可预测性。

到目前为止，强隔离意味着一台机器只运行一个工作负载。借助 Nitro Sandboxes，你可以将许多隔离的 pod 打包到单个节点上，每个 pod 都有自己的 VM 边界。将 pod 打包在一起引出了第二个问题：一个 pod 会不会拖慢它的邻居？每个沙箱运行在自己独立的 CPU 和内存切片中，Nitro Hypervisor 在硬件层面强制执行该切片，因此无论是 EC2 宿主还是邻居 pod 都无法读取其内存或 CPU 状态。pod 在节点上仍然共享的资源，例如网络带宽、磁盘 I/O、DNS 查询、日志输出和连接跟踪（conntrack）条目，默认通过可配置的限流机制加以保护。一个失控的 agent、一个繁重的构建任务或一个繁忙的租户，会在影响相邻 pod 之前先触及自己的限制。借助 AWS Nitro Sandboxes，这些保护默认开启，因此你无需逐节点调优即可获得可预测的性能。

隔离模式将每个 pod 放入自己的虚拟机。目标是保护宿主和相邻 pod 免受容器内部任何情况的影响。

机密模式更进一步。它将甚至机器操作员也视为不可信。加密证明可验证沙箱内运行的确切代码，AWS Key Management Service（AWS KMS）仅在收到证明系统镜像和所配置 Cedar 策略的证明文档时才允许解密。该设计可防止集群管理员读取 pod 的内存。SaaS 提供商可以向客户证明租户数据受到硬件保护，受监管行业可以向审计人员提供加密证据而非文档。

pod 启动时会发生什么。Nitro System 是运行每个 EC2 实例的硬件和 hypervisor。它在专用硬件中隔离实例之间以及实例与宿主之间，而非在你必须配置的软件中。Nitro Sandboxes 基于一项新的 EC2 能力构建，该能力让 Nitro Hypervisor 从运行中的实例中划出一块硬件隔离的 CPU 和内存切片。Amazon EKS 利用该切片为每个沙箱化 pod 提供自己的轻量级 VM。从 pod 的视角来看，这一过程很简短：

机密模式在该流程中增加了证明。Nitro Security Module 度量沙箱内启动的内容，并签署一份证明文档，你的工作负载将其提交给 AWS KMS，因此密钥只会释放给运行你预期镜像和策略的沙箱。具体机制将在本文之后的深度解析文章中介绍。

图 1：隔离边界。沙箱化 pod 运行在 Nitro Partition 内的轻量级 VM 中。节点的 kubelet 仍然看到的是一个普通 pod。

最快的路径是 EKS Auto Mode，其中运行时类存在于每个集群上，无需安装任何 add-on，Auto Mode 会按需配置支持沙箱的节点。如果你运行标准 EKS 并使用自己的节点组或 Karpenter，一旦你的节点运行启用了沙箱的 AMI，相同的 pod spec 即可工作。用户指南详细介绍了如何为 Nitro Sandboxes 构建 AMI。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）