AWS 推出 EKS 隔离与机密 Pod 沙箱方案

一个使用 runtimeClassName: confidential-sandbox 的 pod。父实例不受信任。使用此模式可保护工作负载数据，使其免受节点操作员或受损父实例的侵害。

父实例受信任，而客户机不受信任。目标是保护节点和其他 pod 免受受损工作负载的侵害。父实例保留完整的可观测性和控制权：exec、stdin、日志、统计信息和进程列表均被允许。该策略不固定容器准入字段，因此任何有效的容器规范都会被接受。overlay 文件系统未加密，以加快 pod 启动速度。服务账户令牌不会被复制到沙箱中。允许 IMDS、NTP 和 Pod Identity 凭证，以便依赖放置元数据或 AWS 凭证的工作负载无需自定义策略即可运行。

父实例不受信任，客户机是信任边界。目标是保护工作负载的数据，使其免受节点操作员或受损父实例的侵害。该策略固定每个准入字段（镜像摘要、参数、环境变量、挂载、能力以及安全设置）。exec、stdin 和进程列表被拒绝，因此父实例无法内省客户机。允许 IMDS 和服务账户令牌，因为客户机需要 AWS 凭证和区域元数据来调用 AWS KMS 以获取加密镜像。

运行时类是权威选择器：系统从 runtimeClassName 推导隔离模式，并忽略 pod 规范设置的任何模式注解。您还可以创建混合搭配这些模式设置的自定义配置文件。有关更多信息，请参阅在机密模式下运行 pod。

要运行不得通过网络通信的不受信任或生成的代码，请在 pod 上设置 sandbox.amazonaws.com/network-isolated: "true"。Nitro Sandbox 启动时没有网络设备——没有 TAP、没有 virtio-net、没有 DNS、没有 NTP、没有 IMDS，也没有 Pod Identity 凭证。由于设备是缺失而非被过滤，pod 在两个方向上都没有网络设备。客户机内部的 vsock 通道仍可访问客户机绑定的端口，这会绕过缺失的网络设备，因此这不是绝对隔离。有关更多信息，请参阅网络隔离。

kubectl port-forward 无法工作，kubelet HTTP 或 TCP 探针也无法成功。对于带有此注解的 pod，请使用 exec 探针。日志、exec、stdin 和统计信息继续通过 vsock 通道工作。有关详细信息，请参阅网络隔离。

对于隔离和机密 pod，AWS 负责 Nitro 虚拟机监控程序、Nitro Sandbox 边界和客户机系统镜像。客户负责其容器镜像、Cedar 策略、AWS KMS 密钥策略和应用程序代码。

您的浏览器中已禁用 JavaScript 或 JavaScript 不可用。

要使用 Amazon Web Services 文档，必须启用 JavaScript。请参阅浏览器的帮助页面以获取说明。

感谢您告知我们我们做得很好！

如果您有时间，请告诉我们我们做得对的地方，以便我们做得更多。