你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Kubernetes 服务上的机密容器的安全策略
如机密计算联盟 (CCC) 所述，“机密计算是通过在基于硬件的、经证明的受信任执行环境 (TEE) 中执行计算来保护正在使用的数据。”AKS 机密容器旨在保护正在使用的 Kubernetes pod 数据不被这些 Pod 外部的用户进行未经授权的访问。 每个 Pod 都在实用工具虚拟机 (UVM) 中执行，该虚拟机受 AMD SEV-SNP TEE 保护，保护方式是：加密正在使用的数据，阻止主机操作系统 (OS) 访问数据。 Microsoft 工程师与机密容器 (CoCo) 和 Kata 容器开源社区合作设计和实现了机密容器。
安全策略概述
Kata 容器系统体系结构的主要组件之一是 Kata 代理。 使用 Kata 容器实现机密容器时，代理在基于硬件的 TEE 内部执行，因此是 Pod 的受信任计算基础 (TCB) 的一部分。 如下图所示，Kata 代理提供了一组 ttrpc API，允许 TEE 之外的系统组件创建和管理基于机密的 Kubernetes Pod。 这些其他组件（例如 Kata Shim）不是 Pod 的 TCB 的一部分。 因此，代理必须保护自己免受潜在的错误或恶意 API 调用的影响。
在 AKS 机密容器中，Kata 代理 API 自我保护是通过机密 Pod 所有者指定的安全策略（也称为 Kata 代理策略）实现的。 策略文档包含与每个 Pod 对应的规则和数据，采用行业标准 Rego 策略语言。 实用工具虚拟机 (UVM) 内部策略的执行是使用 Open Policy Agent (OPA)（云原生计算基础 (CNCF) 的一个毕业项目）来实现的。
策略内容
安全策略描述了创建和管理机密 Pod 所需的所有代理 ttrpc API 调用（以及这些 API 调用的参数）。 每个 Pod 的策略文档都是一个文本文件，使用 Rego 语言。 该策略文档包含三个概略性节。
数据
策略数据特定于每个 Pod。 例如，它包含：
- 预计将在 Pod 中创建的容器的列表。
- 默认情况下（出于保密原因）被策略阻止的 API 的列表。
Pod 中每个容器的策略文档中包含的数据的示例：
- 映像完整性信息。
- 在容器中执行的命令。
- 存储卷和装载。
- 执行安全上下文。 例如，根文件系统是否是只读的？
- 该进程是否被允许获得新的特权？
- 环境变量。
- 来自开放容器计划 (OCI) 容器运行时配置的其他字段。
规则
以 Rego 格式指定的策略规则由 OPA 针对来自实用工具虚拟机 (UVM) 外部的每个 Kata 代理 API 调用执行。 代理将所有 API 输入提供给 OPA，OPA 使用规则检查输入是否与策略数据一致。 如果策略规则和数据不允许 API 输入，代理会通过返回“被策略阻止”错误消息来拒绝 API 调用。 下面是一些规则示例：
- 每个容器层都作为只读 virtio 块设备公开给实用工具虚拟机 (UVM)。 使用 Linux 内核的 dm-verity 技术来保护这些块设备的完整性。 dm-verity 哈希树的预期根值包含在策略数据中，在运行时由策略规则进行验证。
- 当检测到意外的命令行、存储装载、执行安全上下文或环境变量时，规则会拒绝创建容器。
默认情况下，策略规则适用于所有 Pod。 genpolicy 工具会生成策略数据，并且特定于每个 Pod。
默认值
在使用策略数据和 API 输入作为参数评估 Rego 规则时，OPA 会尝试找到至少一组根据输入数据返回 true 值的规则。 如果规则未返回 true，OPA 会向代理返回该 API 的默认值。 策略中的默认值示例：
default CreateContainerRequest := false– 表示任何 CreateContainer API 调用都会被拒绝，除非一组策略规则明确允许该调用。default GuestDetailsRequest := true– 表示始终允许从 TEE 外部调用 GuestDetails API，因为此 API 返回的数据对客户工作负荷的机密性不敏感。
将策略发送给 Kata 代理
所有 AKS 机密容器实用工具虚拟机 (UVM) 均使用实用工具虚拟机 (UVM) 根文件系统中包含的通用默认策略启动。 因此，必须在运行时向代理提供与实际客户工作负荷相匹配的策略。 如前所述，策略文本嵌入到 YAML 清单文件中，早在实用工具虚拟机 (UVM) 初始化期间就以这种方式提供给代理。 策略注释贯穿 AKS 机密容器系统的 kubelet、containerd 和 Kata shim 组件。 然后，与 OPA 协同工作的代理会对针对其自身 API 的所有调用强制执行该策略。
该策略是使用不属于 TCB 的组件提供的，因此最初该策略不受信任。 必须通过远程证明来建立策略的可信度，如下一部分所述。
建立对策略文档的信任
在创建实用工具虚拟机 (UVM) 之前，Kata shim 会计算策略文档的 SHA256 哈希，并将该哈希值附加到 TEE。 此操作在策略内容和实用工具虚拟机 (UVM) 之间创建了强有力的绑定。 该 TEE 字段以后无法由实用工具虚拟机 (UVM) 内部或外部执行的软件修改。
收到策略后，代理会验证策略的哈希是否与不可变的 TEE 字段匹配。 如果代理检测到哈希不匹配的情况，则会拒绝传入策略。
在处理敏感信息之前，工作负荷必须执行远程证明步骤，向任何信赖方证明该工作负荷是使用 TEE、OS、代理、OPA 和根文件系统的预期版本执行的。 证明是在实用工具虚拟机 (UVM) 内部运行的容器中实现的，该容器从 AMD SEV-SNP 硬件获取签名的证明证据。 证明证据中的字段之一是前面描述的策略哈希 TEE 字段。 因此，证明服务可以通过将该字段的值与 Pod 策略的预期哈希进行比较来验证策略的完整性。
策略实施
Kata 代理负责执行该策略。 Microsoft 向 Kata 和 CoCo 社区贡献了负责检查每个代理 ttrpc API 调用的策略的代理代码。 在执行与 API 对应的操作之前，代理使用 OPA REST API 来检查策略规则和数据是允许还是阻止调用。