diff --git a/sig/Hygon Arch/assets/CSV/diff.oci-client b/sig/Hygon Arch/assets/CSV/diff.oci-client new file mode 100644 index 0000000000000000000000000000000000000000..f33007f1bd4665874e3b105aada782d88c17873f --- /dev/null +++ b/sig/Hygon Arch/assets/CSV/diff.oci-client @@ -0,0 +1,22 @@ +diff --git a/src/client.rs b/src/client.rs +index d1a3bf0..d1b738d 100644 +--- a/src/client.rs ++++ b/src/client.rs +@@ -270,7 +270,7 @@ impl Default for Client { + config: Arc::default(), + auth_store: Arc::default(), + tokens: TokenCache::new(DEFAULT_TOKEN_EXPIRATION_SECS), +- client: reqwest::Client::default(), ++ client: reqwest::Client::builder().danger_accept_invalid_certs(true).build().expect("Client::new()"), + push_chunk_size: PUSH_CHUNK_MAX_SIZE, + } + } +@@ -323,7 +323,7 @@ impl TryFrom for Client { + Ok(Self { + config: Arc::new(config), + tokens: TokenCache::new(default_token_expiration_secs), +- client: client_builder.build()?, ++ client: client_builder.danger_accept_invalid_certs(true).build()?, + push_chunk_size: PUSH_CHUNK_MAX_SIZE, + ..Default::default() + }) diff --git a/sig/Hygon Arch/assets/CSV/diff.oci-distribution b/sig/Hygon Arch/assets/CSV/diff.oci-distribution new file mode 100644 index 0000000000000000000000000000000000000000..107c688a2d1724a40914f4cb555e45c58484af42 --- /dev/null +++ b/sig/Hygon Arch/assets/CSV/diff.oci-distribution @@ -0,0 +1,13 @@ +diff --git a/src/client.rs b/src/client.rs +index d2a0646..6fc8b5b 100644 +--- a/src/client.rs ++++ b/src/client.rs +@@ -261,7 +261,7 @@ impl TryFrom for Client { + + Ok(Self { + config: Arc::new(config), +- client: client_builder.build()?, ++ client: client_builder.danger_accept_invalid_certs(true).build()?, + push_chunk_size: PUSH_CHUNK_MAX_SIZE, + ..Default::default() + }) diff --git a/sig/Hygon Arch/assets/CSV/diff.reqwest b/sig/Hygon Arch/assets/CSV/diff.reqwest new file mode 100644 index 0000000000000000000000000000000000000000..aac3a0d5fd7e7b31b8d270ea37aec71caa8dc15d --- /dev/null +++ b/sig/Hygon Arch/assets/CSV/diff.reqwest @@ -0,0 +1,57 @@ +diff --git a/src/async_impl/client.rs b/src/async_impl/client.rs +index b321a60..8b825d9 100644 +--- a/src/async_impl/client.rs ++++ b/src/async_impl/client.rs +@@ -171,7 +171,7 @@ struct Config { + + impl Default for ClientBuilder { + fn default() -> Self { +- Self::new() ++ Self::new().danger_accept_invalid_certs(true) + } + } + +@@ -191,7 +191,7 @@ impl ClientBuilder { + #[cfg(feature = "native-tls")] + hostname_verification: true, + #[cfg(feature = "__tls")] +- certs_verification: true, ++ certs_verification: false, + #[cfg(feature = "__tls")] + tls_sni: true, + connect_timeout: None, +@@ -393,7 +393,8 @@ impl ClientBuilder { + tls.danger_accept_invalid_hostnames(!config.hostname_verification); + } + +- tls.danger_accept_invalid_certs(!config.certs_verification); ++ //tls.danger_accept_invalid_certs(!config.certs_verification); ++ tls.danger_accept_invalid_certs(true); + + tls.use_sni(config.tls_sni); + +@@ -1898,14 +1899,14 @@ impl Client { + /// Use `Client::builder()` if you wish to handle the failure as an `Error` + /// instead of panicking. + pub fn new() -> Client { +- ClientBuilder::new().build().expect("Client::new()") ++ ClientBuilder::new().danger_accept_invalid_certs(true).build().expect("Client::new()") + } + + /// Creates a `ClientBuilder` to configure a `Client`. + /// + /// This is the same as `ClientBuilder::new()`. + pub fn builder() -> ClientBuilder { +- ClientBuilder::new() ++ ClientBuilder::new().danger_accept_invalid_certs(true) + } + + /// Convenience method to make a `GET` request to a URL. +@@ -2255,6 +2256,7 @@ impl Config { + if !self.certs_verification { + f.field("danger_accept_invalid_certs", &true); + } ++ f.field("danger_accept_invalid_certs", &true); + + if let Some(ref min_tls_version) = self.min_tls_version { + f.field("min_tls_version", min_tls_version); diff --git a/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-components-integration.png b/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-components-integration.png new file mode 100644 index 0000000000000000000000000000000000000000..dfe61e2801b04e3cb18becce9a61a0a41d5166bd Binary files /dev/null and b/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-components-integration.png differ diff --git a/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-global-roles.png b/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-global-roles.png new file mode 100644 index 0000000000000000000000000000000000000000..dc82019f42d62e29c0c69ee3271bb828edd938e3 Binary files /dev/null and b/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-global-roles.png differ diff --git a/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-hw-sw-running-data-flow.png b/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-hw-sw-running-data-flow.png new file mode 100644 index 0000000000000000000000000000000000000000..ac838c83c771e0cb7c8d5676b9f6dba26cb429d5 Binary files /dev/null and b/sig/Hygon Arch/assets/CSV/kata-3.13-kata-coco-hw-sw-running-data-flow.png differ diff --git "a/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/1-KATA-3.13\346\241\206\346\236\266\345\222\214\350\247\222\350\211\262\344\273\213\347\273\215.md" "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/1-KATA-3.13\346\241\206\346\236\266\345\222\214\350\247\222\350\211\262\344\273\213\347\273\215.md" new file mode 100644 index 0000000000000000000000000000000000000000..70a1375675f1a23d1ab20c32b3fd9ee0eba134d6 --- /dev/null +++ "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/1-KATA-3.13\346\241\206\346\236\266\345\222\214\350\247\222\350\211\262\344\273\213\347\273\215.md" @@ -0,0 +1,174 @@ +# 引言 + +> 如对Kata框架不感兴趣，请直接转到[快速测试海光机密容器（纯单机系统）](3-快速测试海光机密容器（纯单机系统）.md)尝试实践。 + +## Kata使用轻量级虚拟机隔离容器环境 + +Kata是一种轻量级的容器技术，它将每个容器实例隔离在一个单独的轻量级虚拟机中，利用硬件虚拟化技术为容器提供更强的隔离边界。Kata的主要特点是： +- 安全隔离性高：通过将容器运行在独立的虚拟机中，实现了容器之间以及容器与宿主机之间的强隔离。即使某个容器被攻破，攻击者也难以突破虚拟机的隔离边界，从而保护了其他容器和宿主机的安全。 +- 性能接近原生：Kata容器在启动速度和运行性能方面接近传统的Linux容器，同时又具备虚拟机级别的隔离特性。它采用了优化的虚拟化技术和轻量化的虚拟机配置，减少了虚拟化带来的性能开销。 +- 与现有生态系统兼容：Kata容器与主流的容器编排工具k8s和容器运行时（如runc、containerd等）兼容。大多数场景下，用户可以轻松地使用Kata部署现有的容器化应用，无需对应用程序和基础设施进行大规模的修改。 + +## Kata机密容器及其发展史 + +最开始，Kata只是做到了容器的虚拟机隔离，这在某种程度上提高了容器运行的安全性，却无法做到数据级的安全，因为虚拟机的内存对于主机是可见的。 + +机密计算通过TEE硬件技术可以实现使用中的数据保护，恰恰现在大部分机密计算产品也都提供虚拟机级别的数据机密性和完整性保护，`Kata机密容器`便是在原Kata容器基础上，结合机密计算TEE硬件发展起来的。 + +### [KATA-2.5](../5-KATA-2.5/)只是Kata机密容器的起点 + +Kata-2.5机密容器主要是在启动虚拟机之前对VMM（如Qemu）命令行进行扩展，使其能够根据Kata配置添加机密计算Qemu对象。例如，用户在Kata配置文件中打开 *机密虚拟机* 相关配置，这是启动Kata容器时，kata容器运行时会自动在创建虚拟机的VMM命令行中添加机密计算Qemu对象。 + +Kata-2.5机密容器有一个很明显的缺陷。它的容器rootfs是在主机侧创建的，通过`shared fs`设备将容器rootfs共享到虚拟机里，虚拟机里的容器负载动态读写共享的容器rootfs，如果rootfs里有秘密代码和数据，那么这些秘密代码和数据将被暴露无遗。 + +### [KATA-3](../4-KATA-3/)展示了较完整的Kata机密容器雏形 + +> 这里的KATA-3指的是Kata CC-v0.5.0版本，这是基于Kata 3.1.0-rc0开发的专门用于支持机密容器的Kata版本。 + +Kata-3开始将容器的镜像下载和容器rootfs的创建迁移到虚拟机侧进行，确保容器的rootfs只有虚拟机自己可以看到，有效杜绝了`shared fs`的容器rootfs暴露问题。 + +此外，通过镜像加密和签名等技术确保容器镜像的存储安全及完整性。 +- 虚拟机在拉取加密或签名的镜像时，会与`simple-kbs`进行远程认证过程，当远程认证通过时，会从`simple-kbs`请求得到镜像的加密或签名密钥，最终在虚拟机中对签名的镜像验签确认完整性，对加密的镜像layers层层解密并创建出容器的rootfs。 + +`simple-kbs`是一个微服务，包含了秘密数据存储/提供、远程证明服务、启动度量参考值服务3个重要功能。 +- 秘密数据存储/提供：旨在本地存储秘密数据（一般通过后台运行的数据库存储）以及提供秘密数据（通过索引ID从数据库中获取秘密数据）给被证明可信的Kata机密容器/虚拟机 +- 远程证明服务：旨在验证Kata机密容器/虚拟机是否是一个可信的TEE +- 启动度量参考值服务：旨在存储预先设定Kata机密容器/虚拟机的启动度量值（即启动度量参考值，一般通过后台运行的数据库存储），如果Kata机密容器/虚拟机想从`simple-kbs`获取秘密数据，那么除了认证报告是可信的，其启动度量值也要与`simple-kbs`存储的对应启动度量值（通过索引ID从数据库中获取启动度量参考值）吻合。 + +整体上来看，Kata-3已经具备了较完整机密容器的雏形，但是它仍然存在部署和易用性等各方面问题，主要列举如下： +- 主机containerd必须替换成机密容器专有的版本 +- `simple-kbs`的使用和访问方式均不够直观 +- kata配置文件中关于机密容器的相关配置过于复杂 +- Kata虚拟机内拉取的镜像仓库auth配置困难 +- Kata机密容器的rootfs必须挂载到虚拟机的tmpfs中，会大量占用虚拟机内存（缺少安全挂载到虚拟机加密盘上的支持） +- 无法持久存储机密容器（容器退出后，容器rootfs就会丢失，无法找回） +- 自签名私有镜像仓库使用困难 +- 无法配置镜像仓库Mirror + +### [KATA-3.13](../6-KATA-3.13/)逐渐规范化机密容器，逐步云原生化 + +[KATA-3.13](../6-KATA-3.13/)介绍的是Kata-3.13版本，它解决了[KATA-3](../4-KATA-3/)在部署和易用性方面的大多数问题。 +- 通过containerd配置nydus snapshotter插件，通过插件引导通知虚拟机内部拉取镜像 +- 对机密容器各个功能组件做了细致的边界划分，原来的`simle-kbs`使用`kbs（Key-Broker-Service）`，`as（Attestation-Serveice）`，`rvps（Reference-Value-Provider-Service）`微服务系统进行了替代 +- 简化kata配置文件中机密容器相关的字段，大部分关键信息通过agent配置参数传递，直接在pod yaml中添加annotations键/值对信息即可 +- 镜像仓库auth json数据可以存放在`kbs`微服务中，并通过在pod yaml中添加annotations告知auth json数据的访问路径，Kata机密容器/虚拟机在与`kbs`远程认证通过后，可以取得auth json数据 +- 可以配置k8s存储卷资源到pod yaml，Kata机密容器/虚拟机通过Luks创建加密块设备，并在加密块设备上存储容器镜像以及容器rootfs + +此外，随着[operator](https://github.com/confidential-containers/operator)和[trustee-operator](https://github.com/confidential-containers/trustee-operator)的成熟，基于这2个仓库可以实现k8s集群内机密容器环境的快速部署，极大地增加了Kata机密容器的易用性。 + +当然，目前还剩以下几个问题未解决，但解决相关问题的工作已经在进行了，海光会持续更新相关支持到[KATA-3.13](../6-KATA-3.13/)。 +- 无法持久存储机密容器（容器退出后，容器rootfs就会丢失，无法找回） **TODO** +- 自签名私有镜像仓库使用困难 *（[快速测试海光机密容器（纯单机系统）](./3-快速测试海光机密容器（纯单机系统）.md)和[快速测试海光机密容器（复杂多机系统）](./4-快速测试海光机密容器（复杂多机系统）.md)中的使用的虚拟机initrd是经过特殊处理的，可以支持自签名私有镜像仓库，特殊处理并不是普遍适用的方法，正面的解决办法正在进行中）* **TODO** +- 无法配置镜像仓库Mirror **TODO** +- 支持DCU **TODO** + +# [KATA-3.13](../6-KATA-3.13/)原理介绍 + +Kata-3.13机密容器是一个复杂的工作系统，为了让用户更好地理解Kata-3.13机密容器 *各个组件的功能*、*各个组件如何构建*、*各个角色*，这里把Kata-3.13机密容器的整个框架拆分成多个图例进行展示。 +- 图1，展示Kata-3.13机密容器**运行环境**的关键执行流、数据流、组件 +- 图2，展示Kata-3.13机密容器**构建环境**中构建的关键组件及其关系 +- 图3，展示包含Kata-3.13机密容器**运行环境**和**构建环境**的全局角色关系图 + +## 详解Kata-3.13机密容器运行环境的关键执行流、数据流、组件 + +图1 Kata-3.13机密容器**运行环境**的关键执行流、数据流、组件 +![kata-3.13-kata-coco-hw-sw-running-data-flow](../../../assets/CSV/kata-3.13-kata-coco-hw-sw-running-data-flow.png) + +> 为了避免组件过多影响到用户对关键组件的理解，这里没有把运行TEE虚拟机所需的`qemu（虚拟机VMM）`、`bzImage（虚拟机内核）`、`initrd（虚拟机initrd）`、`image（包含虚拟机rootfs的镜像文件）`、`OVMF（虚拟机BIOS）`添加到图1。 + +图1中的黑色箭头线条表示的是不可信的执行流或数据流，橙色箭头线条表示的是机密容器镜像相关的执行流或数据流，绿色箭头线条表示的是与TEE环境验证和秘密数据通信有关的执行流或数据流。图中，有2个例外，就是标记 *17* 和 *19* 的橙色箭头线条，这2个不仅表示了机密容器镜像相关的执行流或数据流，也包含机密容器镜像有关的秘密数据的执行流或数据流（比如加密镜像的密钥，签名镜像的验签公钥）。 + +以下是图1中各个标记的箭头线条含义： +1. `kubelet`通过CRI向`containerd`发送Pod/容器的有关请求。 +2. `containerd`识别到是Kata机密容器的OCI运行时，则使用`nydus-snapshotter`快照器插件获取快照，`nydus-snapshotter`会创建一个后续提供给TEE虚拟机中kata-agent的`容器镜像下载描述数据包`。 +3. `containerd`调用底层的OCI运行时`containerd-shim-kata-v2`来执行Pod/容器有关的具体操作。 +4. `containerd-shim-kata-v2`创建并启动一个TEE虚拟机。 +5. `containerd-shim-kata-v2`与TEE虚拟机中的`kata-agent`通信，由`kata-agent`执行Pod/容器有关的命令。 +6. `nydus-snapshotter`把`容器镜像下载描述数据包`传递给TEE虚拟机中的kata-agent。 +7. `kata-agent`集成的`image-rs`针对加密/签名的容器镜像，与`confidential-data-hub`进程交互获取加密/签名容器的密钥。 +8. `confidential-data-hub`经由`attestation-agent`去进行远程认证，`confidential-data-hub`只有在远程认证通过后，才能与`kbs`（Key-Broker-Service）通信取得秘密数据。 +9. `attestation-agent`发送TEE认证报告给`kbs`，`kbs`将其认证结果返回给`attestation-agent`。这里，`kbs`会有自己的对`as`（Attestation-Service）返回的认证结果的判定策略（resource policy），这会在后续的测试中解释。 +10. `kbs`发送TEE认证报告给`as`，`as`把其认证结果返回给`kbs`。这里，`as`会对TEE认证报告进行验证，并依据自己的判定策略（attestation policy）做一个综合评判，其综合评判的结构化数据作为认证结果返回给`kbs`，这会在后续的测试中解释。 +11. `as`从`rvps`取得参考值数据。这里，`as`自己的判定策略里会要求TEE认证报告中一些字段必须与`rvps`提供的参考值匹配，这些匹配结果会反映在综合评判的机构化数据中，这会在后续的测试中解释。 +12. `image-rs`从`容器镜像下载描述数据包`中提取镜像信息，并从`容器镜像仓库`中拉取镜像manifests，layers等。 +13. `image-rs`把镜像存储到虚拟机本地。 +14. 基于本地存储的镜像创建k8s Pod中的`容器1`、`容器2`。 +15. `容器1`/`容器2`的负载发送秘密数据或TEE认证报告的访问请求给`api-server-rest`，`api-server-rest`把秘密数据或TEE认证报告返回给`容器1`/`容器2`。 +16. `api-server-rest`与`confidential-data-hub`交互获取秘密数据，与`attestation-agent`获取TEE认证报告。 +17. 机密容器所有者信任的角色登录**制作容器镜像的机器**，并在**制作容器镜像的机器**上制作镜像。 +18. 机密容器所有者信任的角色把镜像上传到`容器镜像仓库`。 +19. 机密容器所有者信任的角色把加密/签名镜像的密钥上传到`kbs`，`kbs`存储这些密钥，TEE虚拟机中的`kata-agent`/`image-rs`在远程证明通过后，从`kbs`下载这些密钥，对容器镜像进行验签和解密。 +20. 机密容器所有者信任的角色与`kbs`交互更新秘密数据、更新`kbs`的判定策略（resource policy）等。 +21. 机密容器所有者信任的角色与`as`交互更新`as`的判定策略（attestation policy）等。 +22. 机密容器所有者信任的角色与`rvps`交互更新机密容器所在TEE环境的评估参考值，该参考值用于指定TEE环境的预期配置等。 +23. TEE硬件单元（包含TEE固件等）为虚拟机提供TEE环境，位于TEE环境下的虚拟机内存受到机密性和完整性保护。 + +## 详解Kata-3.13机密容器构建环境中构建的关键组件及其关系 + +图2 Kata-3.13机密容器**构建环境**中构建的关键组件及其关系 +![kata-3.13-kata-coco-components-integration](../../../assets/CSV/kata-3.13-kata-coco-components-integration.png) + +从图2可以看出 ***机密容器组件构建环境*** 构建出的各个组件是用于在 ***机密容器运行环境*** 中运行并提供机密容器能力的。 + +* ***机密容器组件构建环境*** 可以是任意一台C86或X86的主机或虚拟机，构建环境的OS可以是任意OS，经实验在`AnolisOS-23`和`ubuntu-20.04`这2个OS上均是可以实现完全构建的，[KATA-3.13](../6-KATA-3.13/)的[构建方法](./5-用户从0开始-编译-制作-安装-机密容器组件.md)是基于`AnolisOS-23`描述的。 +* ***机密容器运行环境*** 涉及到多个运行的机器： + - **容器镜像仓库的机器**用于作为运行环境所需容器镜像的仓库源。（该机器可以是以下机器的其中一种，只要保持网络连通性即可。） + - 可以是一台独立的物理机。 + - 可以是一台独立的虚拟机。 + - 也可以是与 ***机密容器运行环境*** 其他机器共用环境的一台机器。 + - **制作容器镜像的机器**用于专门制作加密/签名的容器镜像，并把制作好的镜像上传到**容器镜像仓库的机器**中的镜像管理仓库中。该机器是作为机密容器租户可信的一方存在的。（该机器可以是以下机器的其中一种，只要保持网络连通性即可。） + - 可以是一台独立的物理机。 + - 可以是一台独立的虚拟机。 + - 也可以是与**运行TEE认证鉴权、秘密管理的机器**共用环境的一台机器。 + - ***（不建议）*** 也可以是与 ***机密容器运行环境*** 其他机器共用环境的一台机器。（仅限于实验机密容器时这么做，部署环境中建议使用以上3种机器作为**制作容器镜像的机器**，因为**容器镜像仓库的机器**和**运行机密容器的机器**并不被视为是可信的。） + - **运行TEE认证鉴权、秘密管理的机器**用于对TEE虚拟机（以及TEE虚拟机中的容器）进行身份证明、授权，以及传递秘密数据给TEE虚拟机（以及TEE虚拟机中的容器）。该机器是作为机密容器租户可信的一方存在的。（该机器可以是以下机器的其中一种，只要保持网络连通性即可。） + - 可以是一台独立的物理机。 + - 可以是一台独立的虚拟机。 + - 也可以是与**制作容器镜像的机器**共用环境的一台机器。 + - ***（不建议）*** 也可以是与 ***机密容器运行环境*** 其他机器共用环境的一台机器。（仅限于实验机密容器时这么做，部署环境中建议使用以上3种机器作为**运行TEE认证鉴权、秘密管理的机器**，因为**容器镜像仓库的机器**和**运行机密容器的机器**并不被视为是可信的。） + - **运行机密容器的机器**作为机密容器的宿主机，通过宿主机上的一系列组件托起TEE虚拟机（以及TEE虚拟机中容器）的运行。该机器必须是支持TEE的物理主机，且需要保证与**容器镜像仓库的机器**、**制作容器镜像的机器**、**运行TEE认证鉴权、秘密管理的机器**的连通性。 +* ***机密容器构建环境*** 与 ***机密容器运行环境*** 没有强耦合关系，用户可以自己将一台主机或虚拟机作为 ***机密容器构建环境*** 并构建机密容器的组件。 + +在 ***机密容器组件构建环境*** 中： +- 基于[trustee仓库](https://github.com/confidential-containers/trustee)构建出`kbs`、`as`、`rvps`。 + - 这3个组件最终在**运行TEE认证鉴权、秘密管理的机器**上运行。 + - 这3个组件分别既可以是二进制服务程序形式、也可以是容器形式。 +- 基于[guest-components仓库](https://github.com/confidential-containers/guest-components)构建出`CoCo KeyProvider容器镜像`。 + - `CoCo KeyProvider容器`最终在**制作容器镜像的机器**上运行，用于进行机密容器的加密镜像制作。 +- 基于[guest-components仓库](https://github.com/confidential-containers/guest-components)构建出`attestation-agent`、`confidential-data-hub`、`api-server-rest`、`luks-encrypt-storage`。 + - `attestation-agent`、`confidential-data-hub`、`api-server-rest`、`luks-encrypt-storage`这4个是TEE虚拟机的关键组件，会被集成到TEE虚拟机的`initrd`和`rootfs块设备镜像image`中。 + - `attestation-agent`就是常说的`AA`，用于生成认证报告，认证报告会被`kbs`、`as`用于验证TEE身份。 + - `confidential-data-hub`即使常说的`CDH`，用于对机密数据进行请求、处理等。 + - `api-server-rest`就是常说的`ASR`，它可与`AA`和`CDH`进行绑定，TEE虚拟机中的容器通过`ASR`获得`AA`和`CDH`的服务。 + - `luks-encrypt-storage`是一个脚本，用于辅助实现块设备安全挂载，这样机密容器需要的容器镜像、容器rootfs、容器动态存储均落盘到安全挂载的块设备中，避免了对TEE虚拟机内存的大量占用。 +- 基于[kata-containers仓库](https://github.com/kata-containers/kata-containers)构建出`containerd-shim-kata-v2, kata-runtime, etc...`、`kata-agent`、`k8s Pod的pause rootfs`、`initrd`、`rootfs块设备镜像image`。 + - `containerd-shim-kata-v2, kata-runtime, etc...`包含了`containerd-shim-kata-v2`和`kata-runtime, etc...`。其中，`containerd-shim-kata-v2`最终在**运行机密容器的机器**上运行，作为 *k8s软件栈* 中与containerd交互的shim，实现k8s对机密容器生命周期的管理。`kata-runtime, etc...`最终作为**运行机密容器的机器**上的 *kata tools* ，辅助调试、监控等。 + - `kata-agent`是TEE虚拟机中的Pod/容器代理工具，与 *k8s软件栈* 交互，管理TEE虚拟机中的Pod/容器的整个生命周期。`k8s Pod的pause rootfs`作为TEE虚拟机中Pod的pause镜像的rootfs。`kata-agent`、`k8s Pod的pause rootfs`作为TEE虚拟机中的关键组件，会被集成到TEE虚拟机的`initrd`和`rootfs块设备镜像image`中。 + - `initrd`可作为TEE虚拟机启动的rootfs（见**运行机密容器的机器**中的橙色`initrd 或 rootfs块设备image`），其集成了TEE虚拟机中运行机密容器的关键组件。`initrd`、`rootfs块设备镜像image`是互斥使用的。 + - `rootfs块设备镜像image`也是作为TEE虚拟机启动的rootfs存在的（见**运行机密容器的机器**中的橙色`initrd 或 rootfs块设备image`），只是它是以虚拟机块设备形式存在的，其集成了TEE虚拟机中运行机密容器的关键组件。`initrd`、`rootfs块设备镜像image`是互斥使用的。 +- 基于 *TEE虚拟机Linux仓库（如龙蜥的cloud-kernel）* 构建出`虚拟机内核模块`、`虚拟机内核文件bzImage`。 + - `虚拟机内核模块`用于提供TEE虚拟机必须的内核模块，会被集成到TEE虚拟机的`initrd`和`rootfs块设备镜像image`中。 + - `虚拟机内核文件bzImage`是运行TEE虚拟机的Linux内核文件（见**运行机密容器的机器**中的橙色`kernel`）。 +- 基于 *TEE虚拟机OVMF仓库（如龙蜥的edk2）* 构建出`虚拟机BIOS（OVMF）`。 + - `虚拟机BIOS（OVMF）`是启动TEE虚拟机的BIOS文件（**运行机密容器的机器**中的橙色`OVMF`）。 +- 基于 *运行TEE虚拟机的Qemu仓库（如龙蜥的qemu-kvm）* 构建出`运行TEE虚拟机的Qemu`。 + - `运行TEE虚拟机的Qemu`是虚拟机管理器，运行创建、运行TEE虚拟机等（见**运行机密容器的机器**中的橙色`Qemu`）。 +- 基于 *支持TEE虚拟机的主机Linux仓库（如龙蜥的cloud-kernel）* 构建出`支持运行TEE虚拟机的主机内核`。 + - `支持运行TEE虚拟机的主机内核`是**运行机密容器的机器**的主机内核。 + +## 详解Kata-3.13机密容器运行环境和构建环境的全局角色关系图 + +图3 Kata-3.13机密容器**运行环境**和**构建环境**的全局角色关系图 +![kata-3.13-kata-coco-global-roles](../../../assets/CSV/kata-3.13-kata-coco-global-roles.png) + +为了让用户更清晰地理解在一整套从**构建**到**运行**涉及的所有机器和角色，图3提供了机密容器**运行环境**和**构建环境**的全局角色关系图。以下对所有角色进行着重描述（图3中黑色数字圆圈标记了角色）。 +- **角色1**：位于**运行k8s master节点的机器**，是 *k8s集群管理、调度服务方（control-plane node）* 。当然，通过配置 *control-plane node* 可调度启动Pod，并添加`node.kubernetes.io/worker`标签，那么**角色1**也包含了**角色2**，此时，**运行k8s master节点的机器**同时也是**运行机密容器的机器**。 +- **角色2**：位于**运行机密容器的机器**，是 *机密容器负载托管服务方* 。机密容器的租户向**角色2**提出运行机密容器的请求，**角色2**在**运行机密容器的机器**上创建并运行机密容器。 +- **角色3**：位于**容器镜像仓库的机器**，是 *镜像存储服务方* ，用于为机密容器租户提供容器负载。 +- **角色4**：位于**制作容器镜像的机器**，是 *镜像制作服务方* 。**角色7**与**角色4**交互，制作并上传加密/签名镜像到**角色3**。 +- **角色5**：位于**TEE认证鉴权、秘密管理的机器**，是 *认证 & 秘密数据的服务方* 。**角色7**把秘密数据（如镜像解密密钥、镜像验签公钥，等）、认证策略、认证评估参考值等登记到**角色5**，**角色5**对**角色2**上运行的机密容器环境进行身份证明，在证明机密容器环境的身份可信后，将秘密数据传递给**角色2**上的机密容器环境使用。 +- **角色6**：位于 ***机密容器组件构建环境*** ，是 *组件构建服务方* 。**角色7**与**角色6**交互，构建所有机密容器运行所需要的组件，这些组件最终安装到 ***机密容器运行环境*** 的各个机器上，各个机器上的对应角色负责完成机密容器的执行流和数据流。 +- **角色7**：这里把**角色7**独立于 ***机密容器运行环境*** 和 ***机密容器组件构建环境*** ，主要是说明他是一个执行人或机构。**角色7**既可以是机密容器租户，也可以是租户信任的权威第三方。 + - 通过与**角色4**交互，完成机密容器负载镜像的制作和存储。 + - 通过与**角色5**交互，完成：a. 上传机密容器所须的秘密数据；b. 设置机密容器的身份验证策略；c. 登记机密容器身份的参考值。 + - 通过与**角色6**交互，完成机密容器运行所须所有组件的构建。 \ No newline at end of file diff --git "a/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/2-KATA-3.13\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\346\224\257\346\214\201\347\216\260\347\212\266.md" "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/2-KATA-3.13\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\346\224\257\346\214\201\347\216\260\347\212\266.md" new file mode 100644 index 0000000000000000000000000000000000000000..d6483ff339c91e791bb8634b6a7289c0e91950ce --- /dev/null +++ "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/2-KATA-3.13\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\346\224\257\346\214\201\347\216\260\347\212\266.md" @@ -0,0 +1,65 @@ +# KATA-3.13海光机密容器支持情况 + +支持情况见下表1，其中，不支持的部分正在处理中。 + +表1 KATA-3.13海光机密容器支持情况 + +| 功能点 | 是否支持 | +| --- | --- | +| CSV1机密容器 | 支持 | +| CSV2机密容器 | 支持 | +| CSV3机密容器 | 支持 | +| 镜像仓库auth | 支持 | +| 镜像加密 | 支持 | +| 镜像签名 | 支持 | +| 机密容落盘安全存储 | 支持1 | +| 私有镜像仓库 | 1）[快速测试海光机密容器（纯单机系统）](./3-快速测试海光机密容器（纯单机系统）.md)和[快速测试海光机密容器（复杂多机系统）](./4-快速测试海光机密容器（复杂多机系统）.md)支持（该实验中对kata-agent的image-rs进行了微调）
2）正式的支持方案进行中 | +| DCU | 不支持 | + +* 1. 只支持机密容器运行时落盘安全，不支持机密容器持久落盘（机密容器终止后，无法恢复落盘数据） + +# 仓库和版本信息 + +- OS + - Anolis OS 23（[KATA-3.13](../6-KATA-3.13/)的构建和测试都是基于`AnolisOS-23`实践的，所以这里列出OS版本为Anolis OS 23，`ubuntu-20.04`经测试也是可正常构建和测试的） +- Host kernel（龙蜥社区官方仓库） + - url=https://gitee.com/anolis/cloud-kernel.git + - branch=devel-6.6 + - commit=ab224dde9d0e07d1aa69f26c2b3b63b3b37004f5 + - 建议回退commit ad91a2dacbf8c26a446658cdd55e8324dfeff1e7 +- k8s + - version=v1.28.0 +- contrainerd + - version=v1.7.27 +- docker + - version=v28.0.2 +- nydus-snapshotter + - version=v0.13.14 +- kata-containers + - url=https://gitee.com/hanliyang-kata-coco/kata-containers.git + - branch=3.13.0-hygon-arch-sig +- kata guest kernel（龙蜥社区官方仓库） + - url=https://gitee.com/anolis/cloud-kernel.git + - branch=devel-6.6 + - commit=ab224dde9d0e07d1aa69f26c2b3b63b3b37004f5 + - 建议回退commit ad91a2dacbf8c26a446658cdd55e8324dfeff1e7 +- kata qemu（龙蜥社区官方仓库） + - url=https://gitee.com/anolis/qemu-kvm.git + - branch=devel-8.2 + - commit=2738f0c0f26db3d4de536b11c16c45dab598e0c5 +- kata OVMF（龙蜥社区官方仓库） + - url=https://gitee.com/src-anolis-os/edk2.git + - branch=a23 + - commit=47be5c088018a7747a94c4ea7884f187a81e9dbe +- guest-components + - url=https://gitee.com/hanliyang-kata-coco/guest-components.git + - branch=0.10.0-hygon-arch-sig +- trustee + - url=https://gitee.com/hanliyang-kata-coco/trustee.git + - branch=0.11.0-hygon-arch-sig +- operator (CoCo Operator) + - url=https://gitee.com/hanliyang-kata-coco/operator.git + - branch=0.12.0-hygon-arch-sig +- trustee-operator + - url=https://gitee.com/hanliyang-kata-coco/trustee-operator.git + - branch=0.3.0-hygon-arch-sig \ No newline at end of file diff --git "a/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/3-\345\277\253\351\200\237\346\265\213\350\257\225\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\357\274\210\347\272\257\345\215\225\346\234\272\347\263\273\347\273\237\357\274\211.md" "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/3-\345\277\253\351\200\237\346\265\213\350\257\225\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\357\274\210\347\272\257\345\215\225\346\234\272\347\263\273\347\273\237\357\274\211.md" new file mode 100644 index 0000000000000000000000000000000000000000..c021b8edae733c429468204d41568e77d29453bc --- /dev/null +++ "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/3-\345\277\253\351\200\237\346\265\213\350\257\225\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\357\274\210\347\272\257\345\215\225\346\234\272\347\263\273\347\273\237\357\274\211.md" @@ -0,0 +1,465 @@ +# 说明 + +本章节主要用于让用户在纯单机环境中快速测试[KATA-3.13](../6-KATA-3.13/)的机密容器效果。[KATA-3.13框架和角色介绍](./1-KATA-3.13框架和角色介绍.md)中的所有机器均复用同一台物理机器，因此所有角色也都是在这同一台物理机器上进行操作。 + +> 测试的主机OS环境是Anolis OS 23。 + +* 本章节基于已经构建好的机密容器组件进行测试（除了主机内核）。 + * 主机内核构建请参考[编译/制作/安装](./5-用户从0开始-编译-制作-安装-机密容器组件.md)中关于主机内核的部分，用户构建完主机内核后，请将其安装到**运行机密容器的机器**上并用该内核重新启动机器。 +* 本章节使用的已经构建好的机密容器组件`initrd`、`rootfs块设备镜像image`中包含的`kata-agent`经过特殊处理以便基于本地私有镜像仓库快速进行测试，特殊处理的内容如下： + - 对rust reqwest (0.12.5) crate进行源码改动，改动参考[diff.reqwest](../../../assets/CSV/diff.reqwest) + - 对rust oci-client (0.12.1) crate进行源码改动，改动参考[diff.oci-client](../../../assets/CSV/diff.oci-client) + - 对rust oci-distribution (0.11.0)进行源码改动，改动参考[diff.oci-distribution](../../../assets/CSV/diff.oci-distribution) + +# 环境安装 + +## 安装主机内核 + +假设按照[编译/制作/安装](./5-用户从0开始-编译-制作-安装-机密容器组件.md)中关于主机内核的部分编译好了内核rpm包，并将内核rpm包复制到了物理主机。 + +> 以下变量 *KERNEL_RPM_PACKAGES_DIR* 表示的是物理主机上存放主机内核rpm包的目录， *CSV3_MEM_PERCENTAGE* 是主机支持CSV3时，期望传递的内核命令行参数`csv-mem-percentage`的值，`csv-mem-percentage`的说明请参考[1-安装CSV软件](../1-安装CSV软件.md)。 + +```shell +KERNEL_RPM_PAKCAGES_DIR=${your_kernel_rpm_packages_dir} +CSV3_MEM_PERCENTAGE=${your_desired_csv3_mem_percentage} + +sudo yum install -y curl && \ +curl https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/install-host-kernel.sh -o /dev/shm/install-host-kernel.sh && \ +chmod +x /dev/shm/install-host-kernel.sh && \ +/dev/shm/install-host-kernel.sh -d ${KERNEL_RPM_PACKAGES_DIR} -c ${CSV3_MEM_PERCENTAGE} +``` + +## 安装docker、containerd、k8s + +> 以下命令行中的脚本`deploy-k8s-node.sh`的参数`-r control-plane+worker`，用于指定k8s节点的角色，`control-plane+worker`含义是既作为`control-plane node`，也作为`worker node`。

此外，脚本`deploy-k8s-node.sh`可能需要执行2遍，第一遍是检测到主机内核cgroup版本没有打开V1支持时会自动更新内核命令行参数打开cgroup V1，然后提示用户重启物理主机，第2遍是在物理主机重启后，安装、配置docer、containerd、k8s。 + +```shell +curl https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/deploy-k8s-nodes.sh -o /dev/shm/deploy-k8s-nodes.sh && \ +chmod +x /dev/shm/deploy-k8s-nodes.sh && \ +/dev/shm/deploy-k8s-nodes.sh -r control-plane+worker +``` + +## 搭建本地镜像仓库 + +> 以下变量 *REGISTRY_IP_ADDR* 表示搭建本地镜像仓库的机器IP地址， *REGISTRY_PORT* 表示本地镜像仓库的服务端口，端口有效范围为[30000,32767]。 + +```shell +REGISTRY_IP_ADDR=${your_local_registry_ip_address} +REGISTRY_PORT=${your_local_registry_port} + +curl https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/deploy-k8s-local-registry.sh -o /dev/shm/deploy-k8s-local-registry.sh && \ +chmod +x /dev/shm/deploy-k8s-local-registry.sh && \ +/dev/shm/deploy-k8s-local-registry.sh -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} +``` + +## 运行CoCo operator + +CoCo operator： +- 把kata机密容器组件（`containerd-shim-kata-v2`、`kata tools`、`Qemu`、`guest kernel`、`guest OVMF`、`initrd`、`rootfs块设备image`、`nydus-snapshotter`）安装到**k8s集群中的所有标记为`worker`的节点上**。 +- 更新所有标记为`worker`的节点上的containerd配置（包括机密容器runtime，`nydus-snapshotter`快照器配置，等）。 +- 注册机密容器CRD到k8s集群。 + +CoCo operator部署依赖于kata-deploy负载镜像，本章节快速部署使用的kata-deploy负载镜像为`docker.io/robertsonhan/kata-deploy-csv:3.11.0`。 + +```shell +# 在执行deploy-k8s-coco-operator.sh脚本前，先下载CoCo operator中的用于支持海光机密容器的负载镜像，因为该负载镜像太大，影响脚本执行。 +kata_deploy_payload_image_tag="docker.io/robertsonhan/kata-deploy-csv:3.11.0" +sudo -E ctr -n k8s.io image pull ${kata_deploy_payload_image_tag} + +# 执行deploy-k8s-coco-operator.sh脚本，该脚本会把 [operator仓库](https://gitee.com/hanliyang-kata-coco/operator/tree/0.12.0-hygon-arch-sig/) 下载到本地$HOME/workspace/CoCo目录下。 +curl https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/deploy-k8s-coco-operator.sh -o /dev/shm/deploy-k8s-coco-operator.sh && \ +chmod +x /dev/shm/deploy-k8s-coco-operator.sh && \ +/dev/shm/deploy-k8s-coco-operator.sh +``` + +执行以下确认机密容器组件部署成功 + +```shell +kubectl get runtimeclass +``` +``` +NAME HANDLER AGE +kata kata-qemu 9s +kata-clh kata-clh 10s +kata-qemu kata-qemu 10s +kata-qemu-coco-dev kata-qemu-coco-dev 10s +kata-qemu-csv kata-qemu-csv 9s +kata-qemu-csv2 kata-qemu-csv2 9s +kata-qemu-csv3 kata-qemu-csv3 9s +kata-qemu-sev kata-qemu-sev 10s +kata-qemu-snp kata-qemu-snp 10s +kata-qemu-tdx kata-qemu-tdx 10s +``` + +执行以下命令确认containerd的nydus-snapshotter快照器配置成功 + +```shell +ps -elf | grep nydus +``` +``` +4 S root 368216 1 0 80 0 - 742601 - 16:32 ? 00:00:00 /opt/confidential-containers/bin/containerd-nydus-grpc --config /opt/confidential-containers/share/nydus-snapshotter/config-coco-guest-pulling.toml --log-to-stdout +``` + +## 运行KBS微服务系统（TEE认证鉴权、秘密管理） + +KBS微服务系统由`kbs`、`as`、`rvps`共3个服务组成。 + +本章节快速部署使用[trustee-operator仓库](https://gitee.com/hanliyang-kata-coco/trustee-operator/tree/0.3.0-hygon-arch-sig/)将KBS微服务系统部署起来，KBS微服务系统的`kbs`、`as`、`rvps`对应的容器负载镜像分别为：`docker.io/robertsonhan/kbs-grpc-as:trusteev0.11.0`、`docker.io/robertsonhan/coco-as-grpc:trusteev0.11.0`、`docker.io/robertsonhan/rvps:trusteev0.11.0`。 + +```shell +# 下载kbs、as、rvps的负载镜像 +kbs_image_tag="docker.io/robertsonhan/kbs-grpc-as:trusteev0.11.0" +as_image_tag="docker.io/robertsonhan/coco-as-grpc:trusteev0.11.0" +rvps_image_tag="docker.io/robertsonhan/rvps:trusteev0.11.0" +sudo -E ctr -n k8s.io image pull ${kbs_image_tag} && \ +sudo -E ctr -n k8s.io image pull ${as_image_tag} && \ +sudo -E ctr -n k8s.io image pull ${rvps_image_tag} + +# 执行deploy-k8s-kbs-microservices.sh脚本，该脚本会把 [trustee-operator仓库](https://gitee.com/hanliyang-kata-coco/trustee-operator/tree/0.3.0-hygon-arch-sig/) 下载到本地$HOME/workspace/CoCo目录下。 +curl https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/deploy-k8s-kbs-microservices.sh -o /dev/shm/deploy-k8s-kbs-microservices.sh && \ +chmod +x /dev/shm/deploy-k8s-kbs-microservices.sh && \ +/dev/shm/deploy-k8s-kbs-microservices.sh +``` + +执行以下确认KBS微服务系统部署成功 + +```shell +kubectl get pods -n trustee-operator-system +``` +``` +NAME READY STATUS RESTARTS AGE +trustee-deployment-565986b798-pnvtg 3/3 Running 1 (12s ago) 14s +trustee-operator-controller-manager-566447bf59-gz5mn 1/1 Running 0 29s +``` + +## 下载容器镜像制作工具 + +容器镜像制作需要3个基本工具：`CoCo keyprovider`、`skopeo`、`cosign`。其中，`CoCo keyprovider`以容器形式提供镜像加密服务，本章节使用的对应负载镜像为`docker.io/robertsonhan/coco-keyprovider:v0.10.0`，`skopeo`和`cosign`是二进制镜像处理工具。 + +```shell +# 下载CoCo keyprovider负载镜像 +coco_keyprovider_image_tag="docker.io/robertsonhan/coco-keyprovider:v0.10.0" +docker image pull ${coco_keyprovider_image_tag} + +# 安装skopeo、cosign +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/install-skopeo.sh | bash +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/install-cosign.sh | bash +``` + +# 开始测试 + +## 启动简单机密容器 + +* 该测试主要是展示一整套环境搭建出来后，可以正常启动TEE环境保护的容器。 + - 测试中的负载镜像未受到加密/签名保护。 + - 测试中没有与KBS微服务系统（TEE认证鉴权、秘密管理）进行远程认证过程。 + +> 以下变量 *REGISTRY_IP_ADDR* 表示搭建的本地镜像仓库的机器IP地址， *REGISTRY_PORT* 表示本地镜像仓库的服务端口。 + +### CSV机密容器 + +```shell +export test_runtimeclass="kata-qemu-csv" +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-simple-pod.sh | bash -s -- -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} +``` + +执行如下命令可以看到最终Pod `simple-busybox`运行起来了。 + +```shell +kubectl get pods --watch +``` +``` +NAME READY STATUS RESTARTS AGE +my-local-registry-7d77f85cdd-dvlrt 1/1 Running 0 4h26m +simple-busybox 0/1 ContainerCreating 0 12s +simple-busybox 1/1 Running 0 13s +``` + +执行如下命令可以查看启动机密容器的Qemu命令行，Qemu对象`-object sev-guest`的policy属性值为 *3* 。 + +```shell +ps -elf | grep qemu +``` +``` +6 S root 474432 474148 10 80 0 - 704253 - 20:24 ? 00:00:11 /opt/kata/bin/qemu-system-x86_64 -name sandbox-bca283a82219ef234c66e7357342ae86ae6a13a60b84fcce659e2acf4e1abdee,debug-threads=on -uuid e644c4f6-3aa6-46b7-95fc-3b4662e1018b -machine q35,accel=kvm,kernel_irqchip=split,confidential-guest-support=sev -cpu host,pmu=off -qmp unix:fd=3,server=on,wait=off -m 2048M,slots=10,maxmem=64736M -device pci-bridge,bus=pcie.0,id=pci-bridge-0,chassis_nr=1,shpc=off,addr=2,io-reserve=4k,mem-reserve=1m,pref64-reserve=1m -device virtio-serial-pci,disable-modern=false,id=serial0 -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/bca283a82219ef234c66e7357342ae86ae6a13a60b84fcce659e2acf4e1abdee/console.sock,server=on,wait=off -device virtio-scsi-pci,id=scsi0,disable-modern=false -object sev-guest,id=sev,cbitpos=47,reduced-phys-bits=1,kernel-hashes=on,policy=3 -drive if=pflash,format=raw,readonly=on,file=/opt/kata/share/ovmf/OVMFCSV.fd -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -device vhost-vsock-pci,disable-modern=false,vhostfd=4,id=vsock-604571650,guest-cid=604571650 -netdev tap,id=network-0,vhost=on,vhostfds=5,fds=6 -device driver=virtio-net-pci,netdev=network-0,mac=56:92:22:fd:d7:11,disable-modern=false,mq=on,vectors=4 -rtc base=utc,driftfix=slew,clock=host -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic --no-reboot -object memory-backend-ram,id=dimm1,size=2048M -numa node,memdev=dimm1 -kernel /opt/kata/share/kata-containers/vmlinuz-6.6.71-openanolis-142-csv -initrd /opt/kata/share/kata-containers/kata-containers-initrd-2025-04-02-11:46:13.343981683+0800-f6e47b53d-csv.initrd -append tsc=reliable no_timer_check ... +``` + +用户如果觉得不够直观，可以打开`kata-qemu-csv`这个runtimeclass的调试，然后进入Pod `simple-busybox`所属的TEE虚拟机环境，查看内核日志。如下： + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/setup-debug-on-coco-runtime.sh | bash -s -- ${test_runtimeclass} 1 +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-simple-pod.sh | bash -s -- -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} + +# 进入机密容器所属的TEE虚拟机环境 +sandbox_id=$(ps -elf | grep qemu | grep ".* -name sandbox-[0-9a-f]*,.*" | sed "s|\(.* -name sandbox-\)\([0-9a-f]*\)\(,.*$\)|\2|") +sudo /opt/kata/bin/kata-runtime exec ${sandbox_id} +# 在TEE虚拟机环境执行dmesg +dmesg | grep CSV +``` +``` +[ 0.066659] HYGON CSV +``` + +结束测试后关闭runtimeclass的调试，删除测试Pod `simple-busybox`。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/setup-debug-on-coco-runtime.sh | bash -s -- ${test_runtimeclass} 0 +kubectl delete pod simple-busybox +``` + +### CSV2机密容器 + +```shell +export test_runtimeclass="kata-qemu-csv2" +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-simple-pod.sh | bash -s -- -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} +``` + +执行如下命令可以看到最终Pod `simple-busybox`运行起来了。 + +```shell +kubectl get pods --watch +``` +``` +NAME READY STATUS RESTARTS AGE +my-local-registry-7d77f85cdd-dvlrt 1/1 Running 0 4h59m +simple-busybox 0/1 ContainerCreating 0 11s +simple-busybox 1/1 Running 0 14s +``` + +执行如下命令可以查看启动机密容器的Qemu命令行，Qemu对象`-object sev-guest`的policy属性值为 *7* 。 + +```shell +ps -elf | grep qemu +``` + +删除测试Pod `simple-busybox`。 + +```shell +kubectl delete pod simple-busybox +``` + +### CSV3机密容器 + +```shell +export test_runtimeclass="kata-qemu-csv3" +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-simple-pod.sh | bash -s -- -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} +``` + +执行如下命令可以看到最终Pod `simple-busybox`运行起来了。 + +```shell +kubectl get pods --watch +``` +``` +NAME READY STATUS RESTARTS AGE +my-local-registry-7d77f85cdd-dvlrt 1/1 Running 0 5h1m +simple-busybox 0/1 ContainerCreating 0 4s +simple-busybox 1/1 Running 0 16s +``` + +执行如下命令可以查看启动机密容器的Qemu命令行，Qemu对象`-object sev-guest`的policy属性值为 *71* 。 + +```shell +ps -elf | grep qemu +``` + +删除测试Pod `simple-busybox`。 + +```shell +kubectl delete pod simple-busybox +``` + +## 启动获取auth信息 + +* 该测试主要是展示一整套环境搭建出来后，TEE虚拟机/机密容器可以与KBS微服务系统（TEE认证鉴权、秘密管理）进行远程认证。 + - 测试中的负载镜像未受到加密/签名保护。 + +* auth信息可以作为需要 用户名&密码 访问的仓库镜像的凭据，该小节只是简单展示可以通过远程认证从KBS微服务系统获取镜像仓库的auth信息，测试Pod的容器镜像并不与auth信息关联，用户可以修改测试Pod yaml文件，测试需要auth验证通过后才能下载镜像的Pod。 + +> 以下变量 *REGISTRY_IP_ADDR* 表示搭建的本地镜像仓库的机器IP地址， *REGISTRY_PORT* 表示本地镜像仓库的服务端口。

本小节只简单演示CSV3机密容器，如果用户希望测试CSV/CSV2机密容器，可以将变量 *test_runtimeclass* 设置为"kata-qemu-csv"或"kata-qemu-csv2"。

由于用户一开始没有向KBS微服务系统（TEE认证鉴权、秘密管理）提供参考值，所以这里测试时对测试脚本`test-auth-pod.sh`执行2遍，第1遍是观测启动机密容器的Qemu命令行，以便计算出**启动度量值**，用户把计算出的**启动度量值**追加到KBS微服务器系统的`参考值`（rvps管理参考值，在远程认证过程中，把参考值提供给`as`，`as`查看认证报告中的TEE**启动度量值**是否与参考值匹配）中；执行第2遍时，KBS微服务系统会检测出TEE虚拟机/容器的认证报告与`参考值`匹配，并将auth信息返回给TEE虚拟机/容器，最终机密容器负载成功运行。

只要机密容器所属TEE虚拟机启动参数固定（ *OVMF* + *kernel* + *initrd* + *cmdline* + *vCPU型号* + *vCPU个数*），那么其启动度量值就是固定的，所以生产环境中，用户可以把预定义的一系列机密容器配置组合对应的**预期**的**启动度量值**全部提前更新到KBS微服务系统，就可以一次性成功启动机密容器（有远程认证过程的机密容器）。 + +### 第1遍启动Pod + +执行以下命令，可以看到Pod `auth-busybox`运行失败，因为远程认证没有通过。 + +```shell +export test_runtimeclass="kata-qemu-csv3" +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-auth-pod.sh | bash -s -- -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} + +kubectl get pods --watch +``` +``` +NAME READY STATUS RESTARTS AGE +auth-busybox 0/1 CrashLoopBackOff 2 (38s ago) 2m18s +my-local-registry-7d77f85cdd-dvlrt 1/1 Running 0 6h2m +``` + +### 使用工具计算机密容器启动度量值 + +```shell +# 计算启动度量值，并更新到KBS微服务系统的`rvps`服务的`参考值`中 +hygon_csv_type="csv3" && \ +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/setup-rv-to-k8s-kbs-microservices-rvps.sh | bash -s -- -t ${hygon_csv_type} + +# 删除Pod `auth-busybox` +kubectl delete pod auth-busybox +``` +> **注意**：
+> 计算CSV/CSV2机密容器的启动度量值不需要知道TEE虚拟机的 *vCPU型号* 和 *vCPU个数* ，计算CSV3机密容器的启动度量值需要知道TEE虚拟机的 *vCPU型号* 和 *vCPU个数* 。目前，csv3机密容器可以使用的 *vCPU型号* 有: +> - host +> - Dhyana +> - Dhyana-v1 +> - Dhyana-v2 +> - Dhyana-v3 +> - Dharma +> - Dharma-v1 +> +> *vCPU型号* 在/opt/kata/share/defaults/kata-containers/configuration-qemu-csv3.toml中`vcpu_model`字段进行配置。

+当前默认配置成了"host"，这就要求用户在CSV3机密容器的启动摘要时，必须能够知道CSV3机密容器所在的物理CPU Family/Model/Stepping信息，然后基于这些信息去计算启动摘要。这种优点是虚拟机可以尽可能使用主机CPU的特性、功能，缺点是如果部署的多个CSV3机密容器运行在不同物理CPU型号的主机上，启动摘要计算较为麻烦。通过强制指定vCPU的型号为Dhyana/Dhyana-v1/Dhyana-v2/Dhyana-v3/Dharma/Dharma可以使启动摘要的提前计算更为便利。（阅读脚本`setup-rv-to-k8s-kbs-microservices-rvps.sh`了解启动度量值的详细计算过程） + +### 第2遍启动Pod + +执行以下命令，可以看到Pod `auth-busybox`启动成功。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-auth-pod.sh | bash -s -- -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} +kubectl get pods --watch +``` +``` +NAME READY STATUS RESTARTS AGE +auth-busybox 0/1 ContainerCreating 0 8s +my-local-registry-7d77f85cdd-dvlrt 1/1 Running 0 7h33m +auth-busybox 1/1 Running 0 15s +``` + +删除Pod `auth-busybox`。 + +```shell +kubectl delete pod auth-busybox +``` + +## 测试加密镜像 + +同[启动获取auth信息](#启动获取auth信息)，这里的测试也要启动2遍Pod。 + +### 第1遍启动Pod + +执行以下命令，可以看到Pod `encrypted-busybox...`运行失败，因为远程认证没有通过。 + +```shell +export test_runtimeclass="kata-qemu-csv3" +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-encrypted-image-pod.sh | bash -s -- -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} + +kubectl get pods --watch +``` +``` +NAME READY STATUS RESTARTS AGE +encrypted-busybox-74d6d64d86-zjqrx 0/1 CrashLoopBackOff 1 (2s ago) 19s +my-local-registry-7d77f85cdd-dvlrt 1/1 Running 0 29h +encrypted-busybox-74d6d64d86-zjqrx 0/1 RunContainerError 2 (1s ago) 35s +``` + +### 使用工具计算机密容器启动度量值 + +```shell +# 计算启动度量值，并更新到KBS微服务系统的`rvps`服务的`参考值`中 +hygon_csv_type="csv3" && \ +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/setup-rv-to-k8s-kbs-microservices-rvps.sh | bash -s -- -t ${hygon_csv_type} + +# 删除Pod `encrypted-busybox...` +kubectl delete -f $HOME/workspace/pod-workload/encrypted-image-pod.yaml +``` + +### 第2遍启动Pod + +执行以下命令，可以看到Pod `encrypted-busybox...`启动成功。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-encrypted-image-pod.sh | bash -s -- -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} + +kubectl get pods --watch +``` +``` +NAME READY STATUS RESTARTS AGE +encrypted-busybox-74d6d64d86-q5vvf 1/1 Running 0 14s +my-local-registry-7d77f85cdd-dvlrt 1/1 Running 0 29h +``` + +脚本`test-encrypted-image-pod.sh`给Pod容器中传入了秘密至容器文件`/secret`，只有Pod成功启动，才能查看传给Pod容器的消息。 +```shell +kubectl exec -it encrypted-busybox-74d6d64d86-q5vvf -- cat /secret +``` +``` +test image's encryption secret +``` + +关闭Pod `encrypted-busybox...`。 + +```shell +kubectl delete -f $HOME/workspace/pod-workload/encrypted-image-pod.yaml +``` + +## 测试签名镜像 + +同[启动获取auth信息](#启动获取auth信息)，这里的测试也要启动2遍Pod。 + +### 第1遍启动Pod + +执行以下命令，可以看到Pod `signed-busybox`运行失败，因为远程认证没有通过。 + +```shell +export test_runtimeclass="kata-qemu-csv3" +curl https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/test-signed-image-pod.sh -o /dev/shm/test-signed-image-pod.sh && \ +chmod +x /dev/shm/test-signed-image-pod.sh && \ +/dev/shm/test-signed-image-pod.sh -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} + +kubectl get pods --watch +``` +``` +kubectl get pods --watch +NAME READY STATUS RESTARTS AGE +my-local-registry-7d77f85cdd-brg5l 1/1 Running 0 39m +signed-busybox 0/1 ContainerCreating 0 5s +signed-busybox 0/1 RunContainerError 0 16s +``` + +### 使用工具计算机密容器启动度量值 + +```shell +# 计算启动度量值，并更新到KBS微服务系统的`rvps`服务的`参考值`中 +hygon_csv_type="csv3" && \ +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/setup-rv-to-k8s-kbs-microservices-rvps.sh | bash -s -- -t ${hygon_csv_type} + +# 删除Pod `signed-busybox` +kubectl delete pod signed-busybox +``` + +### 第2遍启动Pod + +执行以下命令，可以看到Pod `signed-busybox`启动成功。 + +```shell +/dev/shm/test-signed-image-pod.sh -i ${REGISTRY_IP_ADDR} -p ${REGISTRY_PORT} -r ${test_runtimeclass} + +kubectl get pods --watch +``` +``` +NAME READY STATUS RESTARTS AGE +my-local-registry-7d77f85cdd-brg5l 1/1 Running 0 41m +signed-busybox 0/1 ContainerCreating 0 4s +signed-busybox 1/1 Running 0 13s +``` + +脚本`test-signed-image-pod.sh`中Pod容器会打印一段测试成功的字符串，只有Pod成功启动，才能打印。 +```shell +kubectl logs signed-busybox +``` +``` +Signed image test SUCCESS :) +``` + +关闭Pod `signed-busybox`。 + +```shell +kubectl delete pod signed-busybox +``` \ No newline at end of file diff --git "a/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/4-\345\277\253\351\200\237\346\265\213\350\257\225\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\357\274\210\345\244\215\346\235\202\345\244\232\346\234\272\347\263\273\347\273\237\357\274\211.md" "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/4-\345\277\253\351\200\237\346\265\213\350\257\225\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\357\274\210\345\244\215\346\235\202\345\244\232\346\234\272\347\263\273\347\273\237\357\274\211.md" new file mode 100644 index 0000000000000000000000000000000000000000..59056bd57e14efd3e929077042e0896f05364afa --- /dev/null +++ "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/4-\345\277\253\351\200\237\346\265\213\350\257\225\346\265\267\345\205\211\346\234\272\345\257\206\345\256\271\345\231\250\357\274\210\345\244\215\346\235\202\345\244\232\346\234\272\347\263\273\347\273\237\357\274\211.md" @@ -0,0 +1 @@ +TODO \ No newline at end of file diff --git "a/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/5-\347\224\250\346\210\267\344\273\2160\345\274\200\345\247\213-\347\274\226\350\257\221-\345\210\266\344\275\234-\345\256\211\350\243\205-\346\234\272\345\257\206\345\256\271\345\231\250\347\273\204\344\273\266.md" "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/5-\347\224\250\346\210\267\344\273\2160\345\274\200\345\247\213-\347\274\226\350\257\221-\345\210\266\344\275\234-\345\256\211\350\243\205-\346\234\272\345\257\206\345\256\271\345\231\250\347\273\204\344\273\266.md" new file mode 100644 index 0000000000000000000000000000000000000000..231e2733f50f19f13cc7f2ceb423708536e6c1ec --- /dev/null +++ "b/sig/Hygon Arch/content/2-CSV\346\265\213\350\257\225\346\226\207\346\241\243/6-KATA-3.13/5-\347\224\250\346\210\267\344\273\2160\345\274\200\345\247\213-\347\274\226\350\257\221-\345\210\266\344\275\234-\345\256\211\350\243\205-\346\234\272\345\257\206\345\256\271\345\231\250\347\273\204\344\273\266.md" @@ -0,0 +1,207 @@ +# 说明 + +参考[kata-3.13机密容器构建环境中构建的关键组件及其关系](./1-KATA-3.13框架和角色介绍.md#详解kata-313机密容器构建环境中构建的关键组件及其关系)了解总共需要哪些组件。 + +参考[kata-3.13机密容器运行环境和构建环境的全局角色关系图](./1-KATA-3.13框架和角色介绍.md#详解kata-313机密容器运行环境和构建环境的全局角色关系图)了解总共有哪些角色。以下构建是**角色7**与**角色6**交互，由**角色6**完成构建。 + +> 以下脚本建议在同一台**AnolisOS-23**的机器上（物理机/虚拟机均可）执行，鉴于所有脚本是必须的，建议按序执行。 + +## 构建角色2需要的组件 + +**角色2**：位于**运行机密容器的机器**，是 *机密容器负载托管服务方* 。机密容器的租户向**角色2**提出运行机密容器的请求，**角色2**在**运行机密容器的机器**上创建并运行机密容器。 + +**角色2**需要的组件有： + - CoCo operator kata-deploy payload image，包含以下： + - containerd-shim-kata-v2, kata-runtime, etc... + - TEE虚拟机的initrd，包含以下： + - attestation-agent + - confidential-data-hub + - api-server-rest + - luks-encrypt-storage + - kata-agent (构建时指定"INIT=yes") + - k8s Pod的pause rootfs + - TEE虚拟机内核模块 + - TEE虚拟机的rootfs块设备image，包含以下： + - attestation-agent + - confidential-data-hub + - api-server-rest + - luks-encrypt-storage + - kata-agent (构建时指定"INIT=no") + - k8s Pod的pause rootfs + - TEE虚拟机内核模块 + - TEE虚拟机内核bzImage + - TEE虚拟机BIOS (OVMF) + - 运行TEE虚拟机的Qemu + - 支持运行TEE虚拟机的主机内核 + +### 准备依赖工具（如go、rust、docker等） + +*build-setup-go-rust-docker-etc.sh* + - 用于安装构建环境所需的go，rust，docker，containerd等。 + +> 依赖工具安装完成后，请退出shell会话，然后再重新登入shell会话，以便使环境生效。 + +```shell +sudo yum install -y curl && \ +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-setup-go-rust-docker-etc.sh | bash +``` + +### 构建 CoCo operator kata-deploy payload image + +构建 CoCo operator kata-deploy payload image之前，需要先把 CoCo operator kata-deploy payload image需要包含的组件构建好。 + +#### 构建 containerd-shim-kata-v2, kata-runtime, etc... + +*build-kata-runtime.sh* + - 用于构建、安装containerd-kata-shim-v2 （kata OCI runtime），kata-runtime等工具。 + - 安装目录为`/opt/kata`。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-runtime.sh | bash +``` + +#### 构建 TEE虚拟机内核 （包括bzImage，内核模块） + +*build-kata-guest-kernel.sh* + - 用于构建、安装kata机密容器所需的虚拟机内核。 + - 安装目录为`/opt/kata`。 + - 该脚本会自动把`gitee.com/anolis/cloud-kernel branch:devel-6.6`下载到`/dev/shm/`目录，并在`/dev/shm`目录进行编译过程。 + - 用户需确保`/dev/shm`目录容量足够大（执行`df -h | grep "/dev/shm"`可以看到容量，建议 >= 25GiB），如果`/dev/shm`目录容量不满足需求，请修改脚本，把其中`/dev/shm`改成容量足够大的路径。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-guest-kernel.sh | bash +``` + +#### 构建 运行TEE虚拟机的Qemu + +*build-kata-qemu.sh* + - 用于构建、安装运行kata机密容器的Qemu。 + - 安装目录为`/opt/kata`。 + - 该脚本会自动把`gitee.com/anolis/qemu-kvm branch:devel-8.2`下载到`/dev/shm/`目录，并在`/dev/shm`目录进行编译过程。 + - 用户需确保`/dev/shm`目录容量足够大（执行`df -h | grep "/dev/shm"`可以看到容量，建议 >= 25GiB），如果`/dev/shm`目录容量不满足需求，请修改脚本，把其中`/dev/shm`改成容量足够大的路径。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-qemu.sh | bash +``` + +#### 构建 TEE虚拟机BIOS（OVMF） + +*build-kata-ovmf.sh* + - 用于构建、安装kata机密容器所需的虚拟机bios/OVMF。 + - 安装目录为`/opt/kata`。 + - 该脚本会自动把`gitee.com/src-anolis-os/edk2 branch:a23`下载到`/dev/shm/`目录，并在`/dev/shm`目录进行编译过程。 + - 用户需确保`/dev/shm`目录容量足够大（执行`df -h | grep "/dev/shm"`可以看到容量，建议 >= 25GiB），如果`/dev/shm`目录容量不满足需求，请修改脚本，把其中`/dev/shm`改成容量足够大的路径。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-ovmf.sh | bash +``` + +#### 构建 kata-agent （包含"INIT=yes"和"INIT=no"的构建结果） + +*build-kata-agent.sh* + - 用于构建、安装kata机密容器所需的虚拟机主进程kata-agent，脚本会分别生成用于制作guest image和guest initrd的kata-agent压缩包。 + - 用于制作guest image的kata-agent压缩包会安装到`/dev/shm/kata-agent/kata-agent.tar.xz`，用于制作guest initrd的kata-agent压缩包会安装到`/dev/shm/kata-agent-init/kata-agent-init.tar.xz`。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-agent.sh | bash +``` + +#### 构建 k8s Pod的pause rootfs + +*build-kata-pause.sh* + - 用于构建、安装kata机密容器所需的虚拟机sandbox根镜像pause的rootfs。 + - 安装路径为`$HOME/workspace/CoCo/kata-containers/tools/packaging/kata-deploy/local-build/build/kata-static-pause-image.tar.xz`。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-pause.sh | bash +``` + +#### 构建 attestation-agent,confidential-data-hub,api-server-rest,luks-encrypt-storage + +*build-kata-coco-guest-components.sh* + - 用于构建、安装kata机密容器所需的虚拟机AA（Attestation-Agent）和CDH（Confidential-Data-Hub）等工具，AA与CDH主要用于协助机密容器所需的虚拟机环境认证鉴权、机密数据流转。 + - 安装路径为`/dev/shm/guest-components.tar.xz`。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-coco-guest-components.sh | bash +``` + +#### 构建 TEE虚拟机的initrd + +*build-kata-guest-initrd.sh* + - 用于构建guest initrd，guest initrd用于作为启动kata机密容器对应的虚拟机的内存根文件系统，guest initrd不能与guest image同时使用。 + - 安装目录为`/opt/kata`。 + +```shell +curl https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-guest-initrd.sh -o /dev/shm/build-kata-guest-initrd.sh && \ +chmod +x /dev/shm/build-kata-guest-initrd.sh && \ +/dev/shm/build-kata-guest-initrd.sh +``` + +#### 构建 TEE虚拟机的rootfs块设备image + +*build-kata-guest-image.sh* + - 用于构建guest image，guest image用于作为启动kata机密容器对应的虚拟机时的根文件系统块设备（virtio-blk-pci）。 + - 安装目录为`/opt/kata`。 + +```shell +curl https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-kata-guest-image.sh -o /dev/shm/build-kata-guest-image.sh && \ +chmod +x /dev/shm/build-kata-guest-image.sh && \ +/dev/shm/build-kata-guest-image.sh +``` + +#### 集成以上组件到CoCo operator kata-deploy payload image + +*build-coco-operator-kata-deploy-csv-docker-image.sh* + - 用于构建CoCo operator所需的kata部署镜像（kata-deploy payload image），该脚本会制作名为`kata-deploy-csv:3.11.0`的容器镜像（**运行机密容器的机器**需要该镜像才能把kata机密容器的组件部署到本地，参见[运行coco operator](./3-快速测试海光机密容器（纯单机系统）.md#运行coco-operator)了解细节，**在一个有非常多k8s `worker node`的集群中，每个`worker node`都需要准备好这个镜像，这个镜像很大**，建议用户先将该镜像缓存到本地或存储在方便高速访问的私有镜像仓库中）同时本地存储一份该镜像的导出包文件`$HOME/workspace/CoCo/hygon-csv-kata-deploy.tar`。 + - CoCo operator在运行时需要这个镜像，用户需提前把该镜像放置到合适的镜像仓库中，并在运行CoCo operator时，重定向kata部署镜像到用户的镜像仓库。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-coco-operator-kata-deploy-csv-docker-image.sh | bash +``` + +### 构建 支持运行TEE虚拟机的主机内核 + +*build-host-kernel.sh* + - 用于构建、安装k8s工作节点物理主机的内核。 + - 该脚本会自动把`gitee.com/anolis/cloud-kernel branch:devel-6.6`下载到`/dev/shm/`目录，并在`/dev/shm`目录进行编译过程。 + - 编译完成后，`/dev/shm/openanolis-kernel/rpmbuild/RPMS/x86_64/`目录下会输出rpm包，请把rpm包复制到**角色1**物理机上安装，该安装步骤是**角色1**物理机上的第一步。安装完成后，请修改grub的内核命令行参数`sudo sed -i "s/^\(GRUB_CMDLINE_LINUX=\".*\)\"$/\1 kvm-amd.sev=1 kvm-amd.sev_es=1 csv_mem_percentage=${XX}\"/g" /etc/default/grub; sudo grub2-mkconfig -o /boot/efi/EFI/anolis/grub.cfg`，其中变量`${XX}`表示CSV3可占用总物理内存的百分比，是十进制数字，该十进制数字最大为 *80* ，参数含义的详解请查看[主机Linux内核需配置内核命令行参数](../1-安装CSV软件.md#主机linux内核需配置内核命令行参数)。 + - 用户需确保`/dev/shm`目录容量足够大（执行`df -h | grep "/dev/shm"`可以看到容量，建议 >= 25GiB），如果`/dev/shm`目录容量不满足需求，请修改脚本，把其中`/dev/shm`改成容量足够大的路径。 + - **务必注意：请在上述脚本执行完以后再执行该脚本** + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-host-kernel.sh | bash +``` + +## 构建角色5需要的组件 + +**角色5**：位于**TEE认证鉴权、秘密管理的机器**，是 *认证 & 秘密数据的服务方* 。**角色7**把秘密数据（如镜像解密密钥、镜像验签公钥，等）、认证策略、认证评估参考值等登记到**角色5**，**角色5**对**角色2**上运行的机密容器环境进行身份证明，在证明机密容器环境的身份可信后，将秘密数据传递给**角色2**上的机密容器环境使用。 + +**角色5**需要的组件有： + - kbs (Key-Broker-Service)，既可以是容器形式，也可以是二进制形式，本章节构建的kbs是容器形式。 + - as (Attestation-Service)，既可以是容器形式，也可以是二进制形式，本章节构建的kbs是容器形式。 + - rvps (Reference-Value-Provider-Service)，既可以是容器形式，也可以是二进制形式，本章节构建的kbs是容器形式。 + +*build-coco-kbs-as-rvps-docker-images.sh* + - 用于构建KBS（Key-Broker-Service）、AS（Attestation-Service）、RVPS（Reference-Value-Provider-Service）3个容器镜像，容器镜像名分别为`kbs-grpc-as:trusteev0.11.0`，`coco-as-grpc:trusteev0.11.0`，`rvps:trusteev0.11.0`（这3个镜像的容器需要部署在**TEE认证鉴权、秘密管理的机器**上），同时本地存储一份这3个镜像的导出包文件`$HOME/workspace/CoCo/kbs-grcp-as_trusteev0.11.0.tar`，`$HOME/workspace/CoCo/coco-as-grpc_trusteev0.11.0.tar`，`$HOME/workspace/CoCo/rvps_trusteev0.11.0.tar`。 + - 这3个镜像运行在guest owner的信任域，用于提供对海光kata机密容器的TEE环境认证鉴权服务、秘密存储和提供服务、guest owner定制秘密数据服务、guest owner定制评估策略服务等。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-coco-kbs-as-rvps-docker-images.sh | bash +``` + +## 构建角色4需要的组件 + +**角色4**：位于**制作容器镜像的机器**，是 *镜像制作服务方* 。**角色7**与**角色4**交互，制作并上传加密/签名镜像到**角色3**。 + +**角色4**需要的组件有： + - CoCo KeyProvider，用于制作加密镜像的工具，以容器形式提供服务。 + - skopeo，镜像加密/签名辅助工具，在[KATA-3.13](../6-KATA-3.13/)主要用在镜像加密。（直接在该机器上使用安装脚本安装该工具，参考[下载容器镜像制作工具](./3-快速测试海光机密容器（纯单机系统）.md#下载容器镜像制作工具)） + - cosign，镜像签名工具。（直接在该机器上使用安装脚本安装该工具，参考[下载容器镜像制作工具](./3-快速测试海光机密容器（纯单机系统）.md#下载容器镜像制作工具)） + +*build-coco-keyprovider-docker-image.sh* + - 用于构建CoCo Key-Provider容器镜像，容器镜像名为`coco-keyprovider:v0.10.0`（这个镜像的容器需要部署在**制作容器镜像的机器**上），同时本地存储一份该镜像的导出包文件`$HOME/workspace/CoCo/coco-keyprovider_v0.10.0.tar`。 + +```shell +curl -sSL https://gitee.com/hanliyang-kata-coco/deployment/raw/master/tools/build-and-install/AnolisOS-23/build-coco-keyprovider-docker-image.sh | bash +``` \ No newline at end of file