第 3 章 在 Microsoft Azure Red Hat OpenShift 上部署机密容器
您可以在 Microsoft Azure Red Hat OpenShift 上部署机密容器工作负载。
3.1. 准备 复制链接链接已复制到粘贴板!
在 Azure Red Hat OpenShift 上部署机密容器前,请查看这些先决条件和概念。
3.1.1. 先决条件 复制链接链接已复制到粘贴板!
- 您已在运行机密容器工作负载的集群中安装了最新版本的 Red Hat OpenShift Container Platform。
- 您已在可信环境中的 OpenShift Container Platform 集群中部署了红帽构建的 Trustee。如需更多信息,请参阅 部署红帽构建信任者。
- 您已为用于 worker 节点和 pod 虚拟机(VM)的子网中的通信启用了端口 15150 和 9000。端口启用在 worker 节点上运行的 Kata shim 和 pod 虚拟机上运行的 Kata 代理之间的通信。
3.1.2. 出站连接 复制链接链接已复制到粘贴板!
要让对等 pod 与外部网络(如公共互联网)通信,您必须为 pod 虚拟机(VM)子网配置出站连接。这涉及设置 NAT 网关,并选择性地定义子网如何在 Azure 中与集群的虚拟网络(VNet)集成。
- 对等 pod 和子网
- 对等 pod 在专用 Azure 子网中操作,这需要显式配置出站访问。此子网可以是 OpenShift Container Platform 节点使用的默认 worker 子网,也可以是专门为对等 pod 创建的自定义子网。
- VNet peering
- 使用单独的子网时,VNet peering 会将对等 pod VNet 连接到集群的 VNet,确保内部通信同时保持隔离。这需要在 VNets 间的非覆盖 CIDR 范围。
您可以通过两种方式配置出站连接:
- 默认 worker 子网 :修改现有 worker 子网使其包含 NAT 网关。这更简单并重复使用集群资源,但它提供较少的隔离。
- peer pod VNet:为对等 pod 设置专用 VNet 和子网,附加 NAT 网关,并使用集群 VNet 对等。这在额外的复杂性方面提供了更高的隔离和灵活性。
3.1.3. 对等 pod 资源要求 复制链接链接已复制到粘贴板!
您必须确保集群有足够的资源。
对等 pod 虚拟机(VM)需要位于两个位置的资源:
-
worker 节点。worker 节点存储元数据、Kata shim 资源(
containerd-shim-kata-v2)、remote-hypervisor 资源(cloud-api-adaptor),以及 worker 节点和对等 pod 虚拟机之间的隧道设置。 - 云实例。这是在云中运行的实际对等 pod 虚拟机。
Kubernetes worker 节点中使用的 CPU 和内存资源由 RuntimeClass (kata-remote)定义中包含的 pod 开销 处理,用于创建对等 pod。
在云中运行的对等 pod 虚拟机总数定义为 Kubernetes 节点扩展资源。这个限制是每个节点,由 peer-pods-cm 配置映射中的 PEERPODS_LIMIT_PER_NODE 属性设置。
扩展资源名为 kata.peerpods.io/vm,并允许 Kubernetes 调度程序处理容量跟踪和核算。
在安装 OpenShift 沙盒容器 Operator 后,您可以根据环境要求编辑每个节点的限制。
变异 Webhook 将扩展的资源 kata.peerpods.io/vm 添加到 pod 规格中。如果存在,它还会从 pod 规格中删除任何特定于资源的条目。这可让 Kubernetes 调度程序考虑这些扩展资源,确保仅在资源可用时调度对等 pod。
变异 Webhook 修改 Kubernetes pod,如下所示:
-
变异 Webhook 检查 pod 中的预期的
RuntimeClassName值,该值在TARGET_RUNTIMECLASS环境变量中指定。如果 pod 规格中的值与TARGET_RUNTIMECLASS中的值不匹配,则 Webhook 会在不修改 pod 的情况下退出。 如果
RuntimeClassName值匹配,webhook 会对 pod 规格进行以下更改:-
Webhook 从 pod 中所有容器和 init 容器的
resources字段中删除每个资源规格。 -
Webhook 通过修改 pod 中第一个容器的 resources 字段,将扩展资源(
kata.peerpods.io/vm)添加到 spec。Kubernetes 调度程序使用扩展资源kata.peerpods.io/vm用于核算目的。
-
Webhook 从 pod 中所有容器和 init 容器的
变异 Webhook 排除 OpenShift Container Platform 中的特定系统命名空间。如果在这些系统命名空间中创建了对等 pod,则使用 Kubernetes 扩展资源的资源核算不起作用,除非 pod spec 包含扩展资源。
作为最佳实践,定义集群范围的策略,仅允许在特定命名空间中创建对等 pod。
3.1.4. Initdata 复制链接链接已复制到粘贴板!
initdata 规格提供了一种灵活的方法,来在运行时初始化带有特定于工作负载的数据的 pod,以避免在虚拟机(VM)镜像中嵌入此类数据。
这种方法通过减少机密信息的风险,并通过删除自定义镜像构建来提高灵活性来提高安全性。例如,initdata 可以包含三个配置设置:
- 用于安全通信的 X.509 证书。
- 用于身份验证的加密密钥。
-
可选的 Kata Agent
policy.rego文件,在覆盖默认的 Kata Agent 策略时强制执行运行时行为。
initdata 内容配置以下组件:
- attestation Agent (AA),它通过发送对测试的证据来验证 pod 的可信度。
- 机密数据 Hub (CDH),用于管理 pod 虚拟机中的 secret 和保护数据访问。
- Kata Agent,它强制执行运行时策略并管理 pod 虚拟机内容器的生命周期。
您可以创建一个 initdata.toml 文件,并将其转换为 Base64 编码的 gzip-format 字符串。您可以使用以下方法之一将 initdata 字符串应用到工作负载:
-
全局配置:添加 initdata 字符串作为对等 pod 配置映射中
INITDATA键的值,为所有对等 pod 创建默认配置。 Pod 配置:将 initdata 字符串作为注解添加到 pod 清单,允许自定义各个工作负载。
注意pod 清单中的 initdata 注解覆盖该特定 pod 的对等 pod 配置映射中的全局
INITDATA值。Kata 运行时在创建 pod 时自动处理这个优先级。
然后,您可以从 initdata 文件创建哈希。这个哈希值是必需的,作为红帽构建的 Trustee 的 Reference Value Provider Service (RVPS)配置映射。