Kata Containers 在 IBM Z 上直通 CEX 硬件：Secure Execution 机密容器中的关联密钥配置实战

云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载在 IBM Zs390x平台上Kata Containers 支持将 IBM Crypto ExpressCEX硬件安全模块通过 VFIO 直通到轻量级虚拟机中使容器化工作负载获得硬件级加密加速。当工作负载运行在 IBM Secure ExecutionSE可信执行环境中时CEX 的 EP11 模式还需要额外完成关联密钥association secret的注入与 AP 队列绑定——这些步骤由 Confidential Containers 生态Trustee/KBS 机密数据枢纽 Confidential Data Hub与 Kata agent 协同完成。本文完整覆盖从主机内核要求、关联密钥创建、Trustee 资源配给到启动容器验证的端到端流程并结合 Kata agent 源码解析kbs:///vfio_ap/{mkvp}资源在 guest 内的实际消费路径帮助你在 z16 平台上落地 CEX Secure Execution 的机密容器方案。背景CEX 直通与 Secure Execution 的关系CEX 是 IBM Z 上的硬件密码卡通过 APAdjunct Processor总线暴露给操作系统。Kata 通过 VFIO-AP 将其直通给 guest VM直通粒度是域domain级的即多个 guest 可以安全地共享同一张物理卡的不同 domain。对于 CEX 的 Accelerator 模式和 Enterprise PKCS #11EP11模式在 IBM z16 及更新机型上即便使用 Secure Execution 可信执行环境也支持直通。两种模式的操作复杂度差异很大Accelerator 模式相对简单无需下文步骤。按 Kata Secure Execution 指南 准备好 SE 环境后在 Kata 的configuration.toml中设置vfio_mode vfio和cold_plug_vfio bridge-port再像非 SE 场景一样使用一个 VFIO-AP 中介设备mediated device即可。Kata agent 会自动完成 Secure Execution 绑定SE bind。EP11 模式为保持机密性需要在 guest 内插入一个关联密钥并将其关联到 AP 队列。在 Kata 中这一步的部分工作由 agent 完成但运行前必须做好配给provisioning准备——这正是本文的主体。需要特别说明的限制编写本文档时可信执行环境的设备只能通过ctr、docker、podman等容器引擎的--device选项传入尚不支持经由 Kubernetes 传入Kubernetes 侧的对应提案是 KEP 4113。因此下文的运行工作负载一节都使用docker run --device方式。Kata 的 SE 配置模板印证了这一点configuration-qemu-se.toml.in 中默认即为cold_plug_vfio bridge-port、hot_plug_vfio no-port且vfio_mode的默认值DEFVFIOMODE_SE在构建时按 SE 场景填充——与本文要求的手动配置一致也就是说使用qemu-se配置时冷插直通通道是预置好的。前置条件在开始之前环境需要满足以下条件支持AP 直通 Secure Execution的主机内核。官方支持自 Ubuntu 24.04、RHEL 8.10 与 9.4、SLES 15 SP6 起可用。一个已设置好主密钥的 EP11 domain。此过程中你会拿到主密钥验证模式Master Key Verification PatternMKVP本文后续用它标识 Trustee 中的资源路径。一个由该 domain 创建的 VFIO-AP 中介设备用于直通。创建方法详见下文附录创建 VFIO-AP 中介设备。可用的 Kata Secure Execution 环境搭建步骤见 Kata with SE VMs。从 Kata 容器可达的密钥代理Key Broker ServiceKBS访问且 KBS 装有 IBM Secure Execution 验证器。注意两点提供的 Secure Execution header 必须与 Kata guest 镜像相匹配必须设置好策略允许该 guest 获取对应机密。Kata 的configuration.toml中vfio_mode vfio且cold_plug_vfio bridge-port。其中关于 MKVP 的获取方式原文档脚注如果你有主机访问权限可以在/sys/bus/ap/card${cardno}/${apqn}/mkvps读取 MKVP其中${cardno}是两位十六进制的卡号${apqn}是要直通的 domain 的 APQN例如卡 3 上 domain 0x41 对应card03/03.0041。该信息只有在卡和 domain 尚未被掩码mask以供 VFIO 使用时才可读。如果你没有主机访问权限应向 HSM domain 管理员索取 MKVP。准备关联密钥association secretEP11 的 Secure Execution 工作负载要求把关联密钥插入 guest并将其关联到 AP 队列。在 Kata 中的分工是密钥的创建和配给由你在可信侧完成经由 Trustee实际的插入与关联由 Kata agent 在 guest 内执行。在可信系统上使用 s390-tools 套件中的pvsecret创建关联密钥。假设你已有以下文件主机密钥文档HKDz16.crtguest 的 Secure Execution headerhdr.binCA 证书DigiCertCA.crtIBM 签名密钥ibm-z-host-key-signing-gen2.crt执行以下命令创建一个名为my secret的随机关联密钥并把密钥本体保存到my_random_secret[trusted]# pvsecret create -k z16.crt --hdr hdr.bin -o my_addsecreq \ --crt DigiCertCA.crt --crt ibm-z-host-key-signing-gen2.crt \ association my secret --output-secret my_random_secret命令的关键输入输出参数 / 文件说明-k z16.crt主机密钥文档HKD用于加密 SE 镜像/请求--hdr hdr.bin必须是与你 Kata guest 镜像匹配的那份 SE header也就是同时提供给了 Trustee 的那一份否则 attestation 无法对应--crt DigiCertCA.crtDigiCert 中间 CA 证书用于验证 HKD 链--crt ibm-z-host-key-signing-gen2.crtIBM Z 主机密钥签名证书-o my_addsecreq保存 add-secret 请求本身稍后配给 Trustee 的资源--output-secret my_random_secret保存随机关联密钥本体自动生成my_secret.yaml密钥元信息包含 secret ID配给时必须随密钥一并提供secret ID 的提取该 ID 需要和密钥一起提供可带或不带前导0x。用yq写入my_addsecid[trusted]# yq .id my_secret.yaml my_addsecid通过 Trustee 配给关联密钥密钥和 secret ID 都要通过 Trustee 配给且资源路径以 MKVP 命名空间隔离。Kata agent 在 guest 内期望的资源路径为vfio_ap/${mkvp}/secretvfio_ap/${mkvp}/secret_id其中${mkvp}是 MKVP 的前 16 字节32 个十六进制字符不带前导0x。例如如果你的 MKVP 输出为WK CUR: valid 0xdb3c3b3c3f097dd55ec7eb0e7fdbcb933b773619640a1a75a9161cec00000000 WK NEW: empty -则 Trustee 配给路径应使用db3c3b3c3f097dd55ec7eb0e7fdbcb93。假设 KBS 运行在127.0.0.1:8080认证私钥为kbs.key把上面创建的密钥与 ID 存入 KBS[trusted]# kbs-client --url http://127.0.0.1:8080 config \ --auth-private-key kbs.key set-resource \ --path vfio_ap/db3c3b3c3f097dd55ec7eb0e7fdbcb93/secret \ --resource-file my_addsecreq [trusted]# kbs-client --url http://127.0.0.1:8080 config \ --auth-private-key kbs.key set-resource \ --path vfio_ap/db3c3b3c3f097dd55ec7eb0e7fdbcb93/secret_id \ --resource-file my_addsecid注意两个资源文件对应关系secret资源是pvsecret create -o输出的 add-secret 请求my_addsecreqsecret_id资源是提取出的 ID 文本my_addsecid。路径中的 MKVP 前缀必须与目标 domain 的 MKVP 严格一致agent 正是凭 guest 内读到的 MKVP 去定位资源的。运行工作负载并验证假设中介设备位于/dev/vfio/0用 Kata runtime 运行容器并传入设备[host]# docker run --rm --runtime io.containerd.run.kata.v2 --device /dev/vfio/0 -it ubuntu如果容器内有 s390-tools可以用lszcrypt -V查看可用的 CEX domain 及其 Secure Execution 状态SESTAT 列[container]# lszcrypt -V CARD.DOM TYPE MODE STATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER SESTAT -------------------------------------------------------------------------------------------------------- 03 CEX8P EP11-Coproc online 2 0 14 08 -----XN-F- cex4card - 03.0041 CEX8P EP11-Coproc online 2 0 14 08 -----XN-F- cex4queue usabledomain 的 SESTAT 显示usable说明关联密钥已成功插入并完成绑定/关联。源码解析agent 如何在 guest 内完成绑定与关联上面准备 配给 运行三步只是外部视角。真正的 SE 机密性动作发生在 guest 内由 vfio_device_handler.rs 中的VfioApDeviceHandler仅在 s390x 目标下编译完成理解它有助于排障1. AP 总线重扫描与设备就绪设备处理开始时agent 向 AP 总线的rescan节点写入1强制重扫描若此时pv_guest_bit_set()为真即运行在 SE 环境中而重扫失败错误信息会提示请确认主机内核支持 AP 直通 Secure Execution——这正是前置条件第 1 条在代码里的对应点。对于热插类型DRIVER_VFIO_AP_TYPEagent 通过 uevent 匹配器ApMatcher匹配 sysfs 路径/sys/bus/ap/card{adapter}/{apqn}的 add 事件等待设备出现对于冷插类型DRIVER_VFIO_AP_COLD_TYPE则直接进入check_ap_device检查。2. SE 环境下的绑定bindcheck_ap_device通过pv_core库读取 APQN 信息先调用apqn.set_bind_state(BindState::Bound)完成 Secure Execution 绑定对应 Accelerator 模式下agent 自动完成 SE bind的行为如果该 AP 是 EP11 且 MKVP 为空直接报错Master key verification pattern for AP {address} is unset——即 domain 未设置主密钥对应前置条件第 2 条随后以读到的 MKVP 调用associate_ap_device。3. 从 Confidential Data Hub 取密钥并关联associate_ap_device按 MKVP 构造资源路径let resource_path format!(kbs:///vfio_ap/{mkvp}); let secret_resource_path format!({resource_path}/secret); let secret_id_resource_path format!({resource_path}/secret_id);这与你在 Trustee 侧set-resource的路径vfio_ap/${mkvp}/secret/secret_id一一对应。取数通过 confidential_data_hub/mod.rs 的 CDH 客户端get_cdh_resource→GetResourceServiceClient完成——Confidential Data Hub 是运行在 guest 内、以 ttrpc 方式向 agent 暴露资源获取 API 的组件agent 因此得以间接访问经 KBS attestation 校验后的机密。拿到两个资源后agent 的执行序列是将secret_id文本去掉前导0x并trim_end所以配给时 ID 带不带0x都可以打开 Ultravisor 设备pv_core::uv::UvDevice用 add-secret 请求体执行AddCmduv.send_cmd把密钥插入 guest 的 Ultravisor 密钥环执行ListCmd列出密钥环内容按encode_hex(id) secret_id找到对应条目的槽位索引若找不到报错secret 与 secret ID 不匹配——这就是为什么两个资源必须来自同一次pvsecret create最后apqn.set_associate_state(AssocState::Associated(secret_idx))把密钥槽位关联到该 AP 队列。源码中还有两条值得注意的细节冷插场景DRIVER_VFIO_AP_COLD_TYPE中check_ap_device仅在pv_guest_bit_set()为真时才做 bind/associate——即非 SE 场景直接放行SE 场景才走上述机密路径。这与文档Accelerator 模式自动 bind、EP11 需额外步骤的叙述吻合。代码中留有 TODOinitdata 稳定后将强制 add-secret 请求经用户签名pvsecret create --user-sign-key/pvsecret verify --user-cert。当前版本下该签名校验尚未强制启用。附录创建 VFIO-AP 中介设备前置条件中反复提到的mediated device按 virtcontainers 设备文档创建。IBM Z 使用 AP 总线承载 CEX HSMKata 支持经 VFIO 直通直通以适配器 domain组合为粒度。步骤如下确认内核配置缺失则需重新编译内核模块需通过modprobe加载CONFIG_VFIO_AP CONFIG_VFIO_IOMMU_TYPE1 CONFIG_VFIO CONFIG_VFIO_MDEV CONFIG_VFIO_MDEV_DEVICE CONFIG_S390_AP_IOMMU掩码要直通的适配器与 domain向/sys/bus/ap/apmask和/sys/bus/ap/aqmask写入负数。例如要直通 06.0032$ echo -0x6 | sudo tee /sys/bus/ap/apmask /dev/null $ echo -0x32 | sudo tee /sys/bus/ap/aqmask /dev/null注意掩码之后/sys/bus/ap/card.../mkvps便不再可读所以 MKVP 应在掩码前记录或向管理员索取。创建中介设备向mdev_supported_types/vfio_ap-passthrough/create写入一个 UUID可用uuidgen$ uuidgen | sudo tee /sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough/create a297db4a-f4c2-11e6-90f6-d3b88d6c9525为该设备分配适配器与 domain$ echo 0x6 | sudo tee /sys/devices/vfio_ap/matrix/a297db4a-f4c2-11e6-90f6-d3b88d6c9525/assign_adapter /dev/null $ echo 0x32 | sudo tee /sys/devices/vfio_ap/matrix/a297db4a-f4c2-11e6-90f6-d3b88d6c9525/assign_domain /dev/null确认 IOMMU group 与 /dev/vfio 节点$ readlink /sys/devices/vfio_ap/matrix/a297db4a-f4c2-11e6-90f6-d3b88d6c9525/iommu_group ../../../../kernel/iommu_groups/0 $ ls /dev/vfio 0 vfio此后即可用docker run --device /dev/vfio/0 ...直通。容器内用lszcrypt需等待 configuration time 结束确认卡片可见。仓库中的功能测试 tests/functional/vfio-ap/run.sh 正是按上述流程自动化create_mediated_device函数从lszcrypt输出解析 APQN、写apmask/aqmask释放设备、创建 mdev 并assign_adapter/assign_domain最后用ctr run --device /dev/vfio/${dev_index}在容器内执行lszcrypt验证。该测试对 Go runtime 与 Rust runtimeruntime-rs各覆盖热插hot plug与冷插cold plug两条路径可作为你本地验证的参考脚本。常见排障要点结合文档与 agent 源码出现直通/关联失败时可按以下顺序排查agent 报Failed to rescan AP bus... Verify your host kernel supports AP pass-through with Secure Execution主机内核不满足AP 直通 SE要求升级主机内核参照前置条件的发行版版本。报 Master key verification pattern for AP ... is unsetEP11 domain 未设置主密钥先完成 domain 初始化。报 Failed to read Confidential Data Hub secret kbs:///vfio_ap/...检查 Trustee 中资源路径与 MKVP 前缀是否正确、KBS 的 SE 验证器是否允许该 guest 的 attestationSE header 是否与 Kata guest 镜像匹配、策略是否放行。报 Could not find secret with the ID ... Perhaps there is a mismatch between the provided secret and secret IDsecret与secret_id两个资源来自不同的pvsecret create结果需用同一次创建的输出重新set-resource。lszcrypt -V中 SESTAT 异常确认hdr.bin与 guest 镜像一致、vfio_mode vfio与cold_plug_vfio bridge-port已生效可用kata-runtime kata-env或检查 runtime_config_base 下的 configuration.toml 核对。Kubernetes 场景无法传设备当前受限仅--device可用等待 KEP 4113 对应的能力落地。小结在 IBM Z 上使用 Kata Containers 运行 EP11 Secure Execution 工作负载链路可概括为主机侧SE 能力内核、掩码 AP 并创建 mdev、vfio_mode/cold_plug_vfio配置→可信侧pvsecret create生成关联密钥与 IDkbs-client set-resource按vfio_ap/{mkvp}/...配给 KBS→guest 侧Confidential Data Hub 取数Ultravisor 插入密钥BindState::BoundAssocState::Associated(slot)完成绑定与关联。三个环节各自的失败点在 agent 错误信息中都有明确指向配合lszcrypt -V的 SESTAT 列即可确认端到端成功。赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Kata Containers 快速上手用 kata-deploy 在 Kubernetes 上跑通第一个轻量 VM 容器Kata Containers 快速上手用 kata deploy 在 Kubernetes 上跑通第一个轻量 VM 容器 Kata Containers 是云原生容器运行时Kata Containers Runtime-rs 中的 Passthrough-FD IODragonball VMM 直通式进程 IO 优化实战Kata Containers Runtime rs 中的 Passthrough FD IODragonball VMM 直通式进程 IO 优化实战 Pas云原生容器运行时攻克Devika密钥配置难关从入门到精通的实战指南攻克Devika密钥配置难关从入门到精通的实战指南 你是否曾在配置Devika项目时因API密钥问题屡屡受挫花费数小时却仍无法解决搜索功能失效、AI模型无法人工智能大模型AI Agent代码智能体本地部署前端上一篇Stremio插件终极指南社区精选资源库完全解析下一篇Kaf安全配置详解SASL、SSL和OAuth认证配置教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考