Compartir a través de

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

  • Artículo

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

机密容器构建在 Kata 机密容器和基于硬件的加密基础上，以加密容器内存。 通过在计算过程中防止内存中的数据采用明文可读格式，它建立了新级别的数据保密。 信任是通过硬件证明在容器中获取的，允许通过受信任的实体访问加密的数据。

与 Pod 沙盒一起，可以在 Azure 中运行隔离的敏感工作负载来保护你的数据和工作负载。 哪些因素让容器具有机密性：

  • 透明度：共享敏感应用程序的机密容器环境，可以看到并验证它是否安全。 受信任的计算基础 (TCB) 的所有组件都将开放源代码。
  • 可审核性：你能够验证并查看 CoCo 环境包（包括 Linux 客户操作系统和所有组件）的当前版本。 Microsoft 通过证明而对来宾操作系统和容器运行时环境进行签名以进行验证。 Microsoft 还发布了来宾 OS 版本的安全哈希算法 (SHA)，以生成字符串可听性和控制情景。
  • 完全证明：属于 TEE 的任何内容都应由 CPU 完全测量，且能够远程验证。 AMD SEV-SNP 处理器给出的硬件报告应通过证明声明来反映容器层和容器运行时配置哈希。 应用程序可以在本地提取硬件报表，包括反映来宾 OS 映像和容器运行时的报告。
  • 代码完整性：通过客户定义的容器策略和容器配置（如不可变策略和容器签名），运行时强制始终可用。
  • 与操作员隔离：安全设计采用最低权限和最高隔离，能够屏蔽所有不受信任方，包括客户/租户管理员。 它包括强化现有的 Kubernetes 控制平面对于机密 Pod 的访问 (kubelet)。

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

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

  • 使用 Azure CLI 部署或升级 AKS 群集
  • 将批注添加到 Pod YAML，以将 Pod 标记为作为机密容器运行
  • 启用安全策略的强制实施
  • 在机密计算中部署应用程序

支持的方案

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

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

注意事项

以下是此机密容器预览版的注意事项：

  • 与 runc Pod 和内核隔离 Pod 相比，Pod 启动时间增加。
  • 此版本中不支持从专用容器注册表中拉取容器映像，也不支持拉取源自机密容器 Pod 清单中的专用容器注册表的容器映像。
  • 不支持版本 1 容器映像。
  • 机密和 ConfigMap 的更新不会反映在来宾中。
  • 临时容器和其他故障排除方法，例如对容器执行 exec、记录容器的输出和 stdio（ReadStreamRequest 和 WriteStreamRequest）需要修改并重新部署策略。
  • 策略生成器工具不支持 cronjob 部署类型。
  • 由于容器映像层度量值在安全策略中编码，因此建议在指定容器时不要使用 latest 标记。
  • 服务、负载均衡器和 EndpointSlices 仅支持 TCP 协议。
  • 群集上所有 Pod 中的所有容器都必须配置为 imagePullPolicy: Always。
  • 策略生成器仅支持使用 IPv4 地址的 Pod。
  • 如果在部署 Pod 后使用环境变量方法进行设置，则无法更改 ConfigMap 和机密值。 安全策略将阻止它。
  • 不支持 Pod 终止日志。 当 Pod 将终止日志写入 /dev/termination-log 或自定义位置（如果在 Pod 清单中指定）时，主机/kubelet 无法读取这些日志。 从来宾到该文件的更改不会反映在主机上。

资源分配改术

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

  • CPU：填充码将一个 vCPU 分配给 Pod 内的基本 OS。 如果未指定资源 limits，工作负载没有分配单独的 CPU 共享，则 vCPU 会与该工作负载共享。 如果指定了 CPU 限制，则为工作负载显式分配 CPU 共享。
  • 内存：Kata-CC 处理程序对 UVM OS 使用 2 GB 内存，另外使用 X MB 附加资源，其中 X 资源 limits（如果已在 YAML 清单中指定），因此在未指定限制的情况下会生成 2 GB VM，不会对容器使用隐式内存。 Kata 处理程序对 UVM OS 使用 256 MB 基本内存；如果在 YAML 清单中指定了资源 limits，则还会使用 X MB 附加内存。 如果未指定限制，则会添加 1,792 MB 的隐式限制，从而为容器产生 2 GB VM 和 1,792 MB 的隐式内存。

在此版本中，不支持在 Pod 清单中指定资源请求。 Kata 容器会忽略 Pod YAML 清单中的资源请求，因此，容器不会将请求传递到填充码。 使用资源 limit 而不是资源 requests 为工作负载或容器分配内存或 CPU 资源。

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

后续步骤