带Azure Kubernetes 服务 (AKS)的机密容器（预览版）

机密容器提供一组特性和功能，用于进一步保护标准容器工作负载，以实现更高的数据安全性、数据隐私和运行时代码完整性目标。 Azure Kubernetes 服务 (AKS) 包含 AKS 上的机密容器（CoCo）（预览版）。

机密容器以 Kata Confidential Containers 和硬件级加密为基础，对容器内存进行加密。 AKS 上的机密容器使用 AMD SEV-SNP，目前仅支持 Azure Linux。 通过在计算过程中防止内存中的数据采用明文可读格式，它建立了新级别的数据保密。 信任是通过硬件证明在容器中获取的，允许通过受信任的实体访问加密的数据。

AKS 支持基于 Kata 容器构建的两项功能：机密容器和 Pod 沙盒。 虽然 Pod 沙盒隔离可确保 Pod 不运行在共享内核上，但它并不能保护 Pod 免受来自管理员层面的攻击。 机密容器提供额外的强化层。

体系结构图的屏幕截图，其中显示了 AKS 中的机密容器和 Pod 沙盒。

哪些因素让容器具有机密性：

  • 透明度：可以看到并验证运行敏感应用程序的机密容器环境是否安全。 Microsoft将受信任计算基础（TCB）的所有组件开源。
  • 可审计性：您可以验证并查看包括 Linux 来宾操作系统及所有组件在内的 CoCo 环境包当前使用的是哪个版本。 Microsoft 会对来宾操作系统和容器运行时环境进行签名，以便你可以通过证明机制验证其真实性。 Microsoft还会发布来宾 OS 版本的安全哈希算法（SHA），以提供强大的可审核性和控制性。
  • 完整证明：CPU 会对属于 TEE 的所有内容进行完整度量，并且可进行远程验证。 AMD SEV-SNP 处理器的硬件报告通过证明声明反映容器层和容器运行时配置哈希。 应用程序可以在本地获取硬件报告，包括反映来宾操作系统映像和容器运行时情况的报告。
  • 代码完整性：始终可通过客户定义的容器及容器配置策略来实现运行时强制实施，例如不可变策略和容器签名。
  • 与操作员隔离：采用最低特权和最高隔离保护的安全设计，免受所有不受信任的参与方（包括客户和租户管理员）的防护。 它包括强化现有的 Kubernetes 控制平面 (kubelet) 对保密 Pod 的访问。

通过将这些功能与其他安全措施或数据保护控制结合使用，作为整个体系结构的一部分，可以帮助满足保护敏感信息的法规、行业或治理合规性要求。

本文可帮助你了解机密容器功能，以及如何实现和配置以下任务：

  • 使用 Azure CLI部署或升级 AKS 群集。
  • 在 Pod YAML 中添加注解，将该 Pod 标记为以机密容器方式运行。
  • 在机密计算中部署应用程序。

支持的方案

机密容器（预览版）适用于涉及敏感数据的部署方案。 例如，个人身份信息 (PII) 或具有法规合规性所需的强安全性的任何数据。 容器的一些常见情景包括：

  • 使用 Apache Spark 运行大数据分析，以便在金融行业进行欺诈模式识别。
  • 运行自承载 GitHub 运行程序，以在持续集成和持续部署 (CI/CD) DevOps 实践中安全地对代码进行签名。
  • 使用来自受信任来源的加密数据集对机器学习模型进行机器学习推理和训练。 它仅在机密容器环境中解密以保留隐私。
  • 在零售和数字广告等行业中，作为多方计算的一部分，创建用于 ID 匹配的大数据清理室。
  • 构建机密计算零信任登陆区域，以符合应用程序迁移到云的隐私法规。

局限性

注意事项

  • 与 runc Pod 和内核隔离 Pod 相比，Pod 的启动时间更长。
  • 不支持使用 Docker 映像清单版本 1（v1）架构的容器映像。
  • 若要使用临时容器和其他故障排除方法，例如 exec 容器、容器日志输出，以及 stdio需要修改策略并将其重新部署到启用 ExecProcessRequest、 ReadStreamRequest、 WriteStreamRequest和 CloseStdinRequest。
  • 由于安全策略对容器映像层度量进行编码，因此在指定容器时不要使用该 latest 标记。
  • 服务、负载均衡器和 EndpointSlices 仅支持 TCP 协议。
  • 策略生成器仅支持使用 IPv4 地址的 Pod。
  • 部署 Pod 后，无法基于 ConfigMaps 和机密更改 Pod 环境变量。
  • Pod 清单中的资源 requests 不受支持。 请改用资源 limits，因为 containerd 不会将请求传递给 Kata shim。
  • 不支持 Pod 终止日志。 尽管 Pod 将终止日志写入到 /dev/termination-log （或 Pod 清单中设置的自定义位置），但主机和 kubelet 无法读取这些日志，并且 Pod 对该文件所做的更改不会反映在主机上。
  • 不支持主机网络访问。 无法在 Pod VM 中直接访问主机网络配置。
  • 适用于容器的 Microsoft Defender 不会评估 Kata 运行时 Pod。
  • Kata 容器在 Azure 文件存储 和高性能本地 SSD 上可能无法达到传统容器所能达到的 IOPS 性能上限。

资源分配概述

请务必了解此版本中的内存和处理器资源分配行为。

  • CPU：填充码将一个 vCPU 分配给 Pod 内的基本 OS。 如果未指定资源 limits，则不会为该工作负荷分配单独的 CPU 份额，并且该工作负荷将与其他工作负荷共享 vCPU。 如果指定 CPU 限制，系统会明确为工作负载分配 CPU 份额。
  • 内存，Kata-CC 处理程序：处理程序将 2 GB 内存分配给实用工具虚拟机 （UVM） OS，以及与 YAML 清单中指定的资源 limits 相等的内存。 如果未指定限制，处理程序将创建一个 2 GB VM，且容器没有隐式内存。
  • 内存，Kata 处理程序：该处理程序会为 UVM OS 分配 256 MB 的基本内存，再加上与 YAML 清单中指定的资源 limits 相等的内存。 如果未指定限制，处理程序会添加 1,792 MB 的隐式限制，从而导致容器的 2 GB VM 具有 1,792 MB 的隐式内存。

在此版本中，不支持在 Pod 清单中指定资源请求。 containerd 不会将请求传递给 Kata Shim，因此不会实现基于 Pod 清单资源请求保留资源。 使用资源 limits 而不是资源 requests 为工作负载或容器分配内存或 CPU 资源。

使用 VM 内存支持的本地容器文件系统，写入容器文件系统（包括日志记录）可以填满提供给 Pod 的可用内存。 此条件可能会导致 Pod 崩溃风险。

后续步骤

  • Last updated on