# deployment **Repository Path**: hanliyang-kata-coco/deployment ## Basic Information - **Project Name**: deployment - **Description**: 一系列文档和脚本描述： 1）各软件仓版本基线 2）如何搭建k8s集群及部署CoCo和KBS资源 3）如何运行海光 CSV1/2/3 CoCo容器 - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 3 - **Created**: 2025-03-01 - **Last Updated**: 2025-10-22 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 该项目主要是介绍如何基于hanliyang-kata-coco下的kata及CoCo仓库快速在k8s集群中部署机密容器 ## 版本信息 - OS - Ubuntu 20.04.1 LTS (Focal Fossa) - Host kernel（这里只是一个示例，用户可以选择其他支持该功能的仓库源） - https://gitee.com/openeuler/kernel.git - branch=OLK-6.6 - commit=305d30148bc6eb27489370e9370f84eb88c3a467 - k8s - version=v1.28.0 - contrainerd - version=v1.7.25 - nydus-snapshotter - version=v0.13.13 - kata-containers - https://gitee.com/hanliyang-kata-coco/kata-containers.git - branch=3.13.0-hygon - kata guest kernel（这里只是一个示例，用户可以选择其他支持该功能的仓库源） - https://gitee.com/openeuler/kernel.git - branch=OLK-6.6 - commit=305d30148bc6eb27489370e9370f84eb88c3a467 - kata qemu（这里只是一个示例，用户可以选择其他支持该功能的仓库源） - https://gitee.com/openeuler/qemu.git - branch=qemu-8.2.0 - commit=6a18d7d50dc49eb86ebb74a77b2c86d8ea09a906 - kata OVMF（这里只是一个示例，用户可以选择其他支持该功能的仓库源） - https://gitee.com/src-openeuler/edk2.git - branch=openEuler-24.03-LTS - commit=4b71bcc5f5e9ff09b42993d33463518ba699580e - guest-components - https://gitee.com/hanliyang-kata-coco/guest-components.git - branch=0.10.0-hygon - trustee - https://gitee.com/hanliyang-kata-coco/trustee.git - branch=0.11.0-hygon - operator (CoCo Operator) - https://gitee.com/hanliyang-kata-coco/operator.git - branch=0.12.0-hygon - trustee-operator - https://gitee.com/hanliyang-kata-coco/trustee-operator.git - branch=0.3.0-hygon > 目前围绕： > - openEuler kernel-6.6 > - OpenAnolis kernel-6.6 > - OpenCloudOS kernel-6.6 > - OpenAnolis kernel-5.10 > > 的软件栈均支持CSV3机密容器。 # 本实践文档机密容器简介 本实践文档是围绕着kata-3.13展开的，一个完整的海光机密容器展示涉及到多个角色： - **机密容器负载的k8s工作节点** - 要求k8s工作节点是能够运行海光TEE的物理平台 - **KBS微服务系统**（鉴权、秘密数据管理） - 与 *机密容器负载的k8s工作节点* 没有耦合关系，用户根据需要选择在合适的机器上部署，但需要保证**机密容器负载**能够与**KBS微服务系统**正常通信 - **机密容器镜像制作中心** - 与 *机密容器负载的k8s工作节点* 和 *KBS微服务系统（鉴权、秘密数据管理）* 没有耦合关系，用户根据需要选择在合适的机器上部署，但需要保证**制作的镜像**最终上传到**运行机密容器的kata机密虚拟机**能够访问的镜像仓库中 为了在k8s环境运行海光kata机密容器，除了安装k8s软件本身之外，我们需要准备： - 角色**机密容器负载的k8s工作节点**运行的CoCo operator依赖的kata部署负载容器镜像：`kata-deploy-csv:3.11.0` - CoCo operator运行请参考：[运行CoCo operator](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/README.md#%E6%89%A7%E8%A1%8Ccoco-operator) - 包括了`kata各个组件`、`containerd配置`管理等 - 以下是`kata各个组件`到`kata-deploy-csv:3.11.0`容器镜像的逻辑图 - `kata-deploy-csv:3.11.0`容器镜像的**制作环境**与**运行环境**没有耦合关系 - 在ubuntu-20.04环境下构建这些组件时，请参考[ubuntu-20.04](./tools/build-and-install/ubuntu-20.04/)下的对应脚本 - 在AnolisOS-23环境下构建这些组件时，请参考[AnolisOS-23](./tools/build-and-install/AnolisOS-23/)下的对应脚本 ![机密容器kata虚拟机运行的组件关系图](./assets/机密容器kata虚拟机运行的组件关系图.png) - 角色**KBS微服务系统**运行的3个容器镜像：Key Broke Service容器镜像`kbs-grpc-as:trusteev0.11.0`，Attestation Service容器镜像`coco-as-grpc:trusteev0.11.0`，Reference Value Provider Service容器镜像`rvps:trusteev0.11.0` - KBS微服务系统运行请参考：[运行KBS微服务](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/README.md#%E8%BF%90%E8%A1%8Ckbs%E6%9C%8D%E5%8A%A1%E7%BB%84%E4%BB%B6trustee-operator) - 以下是KBS微服务系统3个容器镜像的生成逻辑图 - KBS微服务系统的**制作环境**与**运行环境**没有耦合关系 - 在ubuntu-20.04环境下构建这些组件时，请参考[ubuntu-20.04](./tools/build-and-install/ubuntu-20.04/)下的对应脚本 - 在AnolisOS-23环境下构建这些组件时，请参考[AnolisOS-23](./tools/build-and-install/AnolisOS-23/)下的对应脚本 ![机密容器KBS鉴权数据管理微服务系统组件关系图](./assets/机密容器KBS鉴权数据管理微服务系统组件关系图.png) - 角色**机密容器镜像制作中心**需要的3个工具：CoCo Key Provider容器镜像`coco-keyprovider:v0.10.0`，`skopeo`，`cosign` - CoCo Key Provider制作加密镜像请参考：[验证镜像加密功能](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/README.md#%E9%AA%8C%E8%AF%81%E9%95%9C%E5%83%8F%E5%8A%A0%E5%AF%86%E5%8A%9F%E8%83%BD) - 以下是 CoCo Key Provider容器镜像，skopeo，cosign的生成逻辑图 - 镜像制作工具的**制作环境**与**运行环境**没有耦合关系 - 在ubuntu-20.04环境下构建这些组件时，请参考[ubuntu-20.04](./tools/build-and-install/ubuntu-20.04/)下的对应脚本 - 在AnolisOS-23环境下构建这些组件时，请参考[AnolisOS-23](./tools/build-and-install/AnolisOS-23/)下的对应脚本 ![机密容器安全镜像制作组件关系图](./assets/机密容器安全镜像制作组件关系图-v0.png) # 安装docker, containerd, k8s **可执行[脚本](./tools/build-and-install/ubuntu-20.04/deploy-k8s-master.sh)** ## 切换到工作目录 ```shell cd $HOME/workspace/CoCo ``` ## 清理 > 如果系统上之前环境被污染，建议执行以下步骤清除机密容器等混乱的资源 ```shell command -v kubectl > /dev/null if [ $? -eq 0 ]; then kubectl delete -k $(pwd)/operator/config/samples/ccruntime/default/ || true kubectl delete -k $(pwd)/operator/config/release/ || true fi command -v kubeadm > /dev/null if [ $? -eq 0 ]; then sudo kubeadm reset fi command -v ctr > /dev/null if [ $? -eq 0 ]; then sudo ctr -n k8s.io image ls | awk '{print $1}' | xargs -n1 sudo ctr -n k8s.io image rm fi sudo systemctl stop docker || true sudo systemctl stop containerd || true sudo pkill -f containerd || true # cleanup metadatas, if not, the nydus may work improperly sudo rm -rf /tmp/nydus-snapshotter || true # just for local sudo rm -rf /opt/confidential-containers || true sudo rm -rf /opt/containerd/ || true sudo rm -rf /var/run/containerd-nydus || true sudo rm -rf /var/run/containerd || true sudo rm -rf /var/lib/containerd-nydus || true sudo rm -rf /var/lib/containerd || true ``` ## 禁止swap，配置内核模块，配置系统参数 ```shell # 临时禁用 sudo swapoff -a # 永久禁用，编辑 /etc/fstab 文件，注释掉包含 swap 的行 sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab # 加载必要的内核模块 sudo modprobe overlay sudo modprobe br_netfilter # 创建并编辑系统参数文件 cat < /dev/null sudo apt update sudo systemctl stop docker || true sudo systemctl stop containerd || true sudo pkill -f containerd || true # cleanup metadatas, if not, the nydus may work improperly sudo rm -rf /var/lib/containerd/* || true sudo apt install -y docker-ce docker-ce-cli containerd.io if [ -e /etc/docker/daemon.json ] && [ $(wc -l /etc/docker/daemon.json | awk '{print $1}') -gt 2 ]; then if [ $(grep -c 'registry.cn-hangzhou.aliyuncs.com' /etc/docker/daemon.json) -eq 0 ]; then sed -i "1a\ \"registry-mirrors\": [\"https://registry.cn-hangzhou.aliyuncs.com\"]," /etc/docker/daemon.json fi else sudo mkdir -p /etc/docker || true cat < 上述operator负载中安装的nydus-snapshotter版本太高，与主机侧的原生containerd不兼容。为了解决这个问题，手动安装并运行nydus-snapshotter。 ```shell # 进入工作目录 cd $HOME/workspace/CoCo/ # 下载、安装nydus-snapshotter nydus_snapshotter_download_dir=$(pwd)/nydus-downloaded nydus_snapshotter_install_dir="/tmp/nydus-snapshotter" nydus_snapshotter_url=https://github.com/containerd/nydus-snapshotter nydus_snapshotter_version="v0.13.13" ARCH=$(uname -m) golang_arch=$(case "$ARCH" in aarch64) echo "arm64" ;; ppc64le) echo "ppc64le" ;; x86_64) echo "amd64" ;; s390x) echo "s390x" ;; esac) release_tarball="nydus-snapshotter-${nydus_snapshotter_version}-linux-${golang_arch}.tar.gz" if [ ! -d "$nydus_snapshotter_download_dir" ]; then mkdir -p $nydus_snapshotter_download_dir fi if [ ! -d "$nydus_snapshotter_install_dir" ]; then mkdir -p $nydus_snapshotter_install_dir fi sudo rm -rf ${nydus_snapshotter_install_dir}/* pushd $nydus_snapshotter_download_dir if [ ! -e ${release_tarball} ]; then curl -OL ${nydus_snapshotter_url}/releases/download/${nydus_snapshotter_version}/${release_tarball} fi sudo tar -zxf ${release_tarball} -C ${nydus_snapshotter_install_dir} --strip-components=1 popd # $nydus_snapshotter_download_dir # 运行nydus-snapshotter sudo /tmp/nydus-snapshotter/containerd-nydus-grpc \ --config /opt/confidential-containers/share/nydus-snapshotter/config-coco-guest-pulling.toml \ --log-to-stdout ``` # 运行简单的海光机密容器 ## 运行海光CSV1机密容器 ```shell cat < 变量${LOCAL_REGISTRY}是用户自己的私有仓库地址和端口号，变量${kbs_as_rvps_image_tag}在[作KBS微服务系统的各个容器镜像](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/how-to-build/%E5%88%B6%E4%BD%9CKBS%E5%BE%AE%E6%9C%8D%E5%8A%A1%E7%B3%BB%E7%BB%9F%E7%9A%84%E5%90%84%E4%B8%AA%E5%AE%B9%E5%99%A8.md)已经定义。 ```shell pushd $HOME/workspace/CoCo/trustee-operator/ sed -i "s#value: ghcr.io/confidential-containers/staged-images/kbs-grpc-as:latest#value: ${LOCAL_REGISTRY}/kbs-grpc-as:${kbs_as_rvps_image_tag}#g" config/manager/manager.yaml sed -i "s#value: ghcr.io/confidential-containers/staged-images/coco-as-grpc:latest#value: ${LOCAL_REGISTRY}/coco-as-grpc:${kbs_as_rvps_image_tag}#g" config/manager/manager.yaml sed -i "s#value: ghcr.io/confidential-containers/staged-images/rvps:latest#value: ${LOCAL_REGISTRY}/rvps:${kbs_as_rvps_image_tag}#g" config/manager/manager.yaml popd ``` ## 运行trustee-operator ### 运行trustee-operator控制器负载 ```shell kubectl apply -k $HOME/workspace/CoCo/trustee-operator/config/default/ kubectl get pods -n trustee-operator-system ``` * 可以看到控制器负载已经成功运行 ``` NAME READY STATUS RESTARTS AGE trustee-operator-controller-manager-6d58bd55d7-rsfk2 1/1 Running 0 2m17s ``` ### 运行KBS微服务负载 ```shell kubectl apply -k $HOME/workspace/CoCo/trustee-operator/config/samples/microservices/ kubectl get pods -n trustee-operator-system ``` * 可以看到KBS微服务负载已经成功运行 ``` NAME READY STATUS RESTARTS AGE trustee-deployment-7d888494db-d8vr5 3/3 Running 1 ( ago) 21s trustee-operator-controller-manager-6d58bd55d7-rsfk2 1/1 Running 0 4m37s ``` # 验证远程认证功能 > 主要是验证kata虚拟机中AA（Attestation-Agent）与KBS微服务系统可以正常远程证明。 > > [测试脚本](samples/test-auth.sh)包含了大致测试的流程。 ## 首先，准备好启动的pod资源和配置 ```shell pushd $HOME/workspace/CoCo/deployment/samples export kbs_namespace="trustee-operator-system" export kbs_deploy="trustee-deployment" export kbs_pod_ip_addr="$(kubectl get pods -n $kbs_namespace -o wide | \ grep $kbs_deploy | \ sed "s/^.* \([0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\) .*$/\1/g")" export kbs_resource_dir="/opt/confidential-containers/kbs/repository" export KBS_KEY_PATH="default/containers/auth" export auth_conf_file=auth-pod.json export pod_yaml=auth.yaml export pod_name="nginx" export pod_container_image="${your_image}" export pod_runtimeclass="kata-qemu-csv3" export AUTHENTICATED_IMAGE="$pod_container_image" export AUTHENTICATED_IMAGE_NAMESPACE="$(echo "$AUTHENTICATED_IMAGE" | cut -d':' -f1)" export AUTHENTICATED_IMAGE_USER="${your_credential_username}" export AUTHENTICATED_IMAGE_PASSWORD="${your_credential_password}" export K8S_SECRET_NAME="cococred" # 生成credential文件 cat < $auth_conf_file { "auths": { "${AUTHENTICATED_IMAGE_NAMESPACE}": { "auth": "$(echo ${AUTHENTICATED_IMAGE_USER}:$AUTHENTICATED_IMAGE_PASSWORD} | base64 -w 0)" } } } EOF # 将credential文件上传到KBS存储目录 kubectl exec deploy/$kbs_deploy \ -c kbs -n $kbs_namespace \ -- mkdir -p "$kbs_resource_dir/$(dirname "$KBS_KEY_PATH")" cat $auth_conf_file | kubectl exec -i deploy/$kbs_deploy \ -c kbs -n $kbs_namespace \ -- tee "$kbs_resource_dir/${KBS_KEY_PATH}" > /dev/null # 创建一个crecential的secret，机密容器启动之前，containerd的nydus-snapshotter需要该信息 kubectl create secret docker-registry "${K8S_SECRET_NAME}" \ --docker-server="https://${AUTHENTICATED_IMAGE_NAMESPACE}" \ --docker-username="${AUTHENTICATED_IMAGE_USER}" \ --docker-password="${AUTHENTICATED_IMAGE_PASSWORD}" # 设置pod的yaml文件 cp $pod_yaml.template $pod_yaml sed -i "s!MARK_KBS_KEY_PATH!${KBS_KEY_PATH}!g" $pod_yaml sed -i "s!MARK_KBS_POD_IP_ADDR!$kbs_pod_ip_addr!g" $pod_yaml sed -i "s!MARK_POD_NAME!${pod_name}!g" $pod_yaml sed -i "s!MARK_POD_CONTAINER_IMAGE!${pod_container_image}!g" $pod_yaml sed -i "s!MARK_POD_RUNTIMECLASS!${pod_runtimeclass}!g" $pod_yaml sed -i "s!MARK_SECRET_NAME!${K8S_SECRET_NAME}!g" $pod_yaml ``` ## 确定机密容器的启动度量值 > 只要机密容器所属虚拟机启动参数固定（**OVMF+kernel+initrd+cmdline+vCPU型号+vCPU个数**），那么其启动度量值就是固定的。这里的例子是先确定一下kata-agent，CDH等虚拟机组件需要的参数，然后临时启动一下并抓取到预期的QEMU启动参数信息，依据这些信息计算出预期的启动度量值。 ```shell # 先试着启动一下pod，这样我们的辅助工具可以计算出预期的启动度量值。请注意：实际部署中，用户需批量确定各个pod启动要件（**OVMF+kernel+initrd+cmdline+vCPU型号+vCPU个数**）并批量计算出各种部署的pod的预期启动度量值 kubectl apply -f $pod_yaml # 计算启动度量值 pushd ../tools/measurement/ measure=$(./csv-calc-measurement.sh csv3 | \ grep "MEASUREMENT => " | sed "s/MEASUREMENT => //" | \ sed 's/^[[:space:]]*//') echo $measure popd # .../measurement # 删除pod，这里只是为了得到启动摘要值。由于配置大多是固定的，用户可以一次实验获取批量pod的预期启动摘要值计算方法，因为ovmf+kernel+initrd+cmdline+vCPU型号+vCPU个数 这些几乎都可以固定下来的。 kubeclt delete -f $pod_yaml popd # .../samples ``` > **请注意**：
> 目前，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可以使启动摘要的提前计算更为便利。

> 用户可以查看以下2个文件了解如何计算启动度量值
> - [采集机密容器所属虚拟机度量组件信息并调用启动度量值计算脚本输出结果](tools/measurement/csv-calc-measurement.sh) > - [计算启动度量值的脚本](tools/measurement/csv-measure.py) ## 将度量值更新到KBS微服务系统中rvps中 ```shell pushd $HOME/workspace/CoCo/trustee-operator/config/samples/microservices/hygon/ # 首先也更新一下KBS微服务系统中的as策略引擎，比如： ## measurement必须与rvps中的一致 ## 容器所处的机密虚拟机policy中必须有csv3,nodbg,es等比特 # 以上这些示例均在$HOME/workspace/CoCo/trustee-operator/config/samples/microservices/hygon/dbg-attestation-policy.rego中有所体现 ./tool-operator-on-kbs-as-rvps.sh as "tee" # 把上面计算的机密容器启动度量值添加到rvps的json参考值文件中 cat > dbg-reference-values.json < 该实验是使用CoCo Key Provider创建加密镜像，并把镜像的密钥上传到KBS中，机密容器启动过程中会与通过远程认证与KBS建立资源访问通道，并从KBS取得镜像密钥解密镜像并挂载到rootfs。 > > [测试脚本](samples/test-encryption.sh) 大致包含了测试的流程。 ## 制作CoCo Key Provider容器镜像和skopeo工具 > 在进行后续镜像加密测试之前请确保CoCo Key Provider容器和skopeo工具已经准备好 参考[制作CoCo Key Provider容器镜像](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/how-to-build/%E5%88%B6%E4%BD%9CCoCo%20Key%20Provider%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F.md) ## 制作加密镜像 ```shell pushd $HOME/workspace/CoCo/deployment/samples export confidential_string="test image's encryption secret" export skopeo_bin=$(which skopeo) export kbs_namespace="trustee-operator-system" export kbs_deploy="trustee-deployment" export kbs_pod_ip_addr="$(kubectl get pods -n $kbs_namespace -o wide | \ grep $kbs_deploy | \ sed "s/^.* \([0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\) .*$/\1/g" )" export kbs_resource_dir="/opt/confidential-containers/kbs/repository" export pod_yaml=encryption.yaml export pod_name="nginx" export pod_runtimeclass="kata-qemu-csv3" export pod_container_image_decrypted="${your_decrypted_image}" export pod_container_image_encrypted="${your_encrypted_image}" export UNENCRYPTED_IMAGE="${your_decrypted_image}" export ENCRYPTED_IMAGE="${your_encrypted_image}" export coco_keyprovider_image="${your_coco_keyprovider_image}" # 定义密钥和资源定位符 export KBS_KEY_FILE="image_key" if [ ! -e $KBS_KEY_FILE ]; then head -c 32 /dev/urandom | openssl enc > "$KBS_KEY_FILE" fi export KBS_KEY_B64="$(base64 < $KBS_KEY_FILE)" export KBS_KEY_PATH="/default/image_key/$pod_name" export KBS_KEY_ID="kbs://${KBS_KEY_PATH}" # 制作基础镜像 sudo docker build -t $UNENCRYPTED_IMAGE - < /secret EOF # 制作加密镜像 sudo rm -rf oci/{input,output} || true mkdir -p oci/{input,output} $skopeo_bin copy docker-daemon:$UNENCRYPTED_IMAGE dir:./oci/input docker run \ -v "${PWD}/oci:/oci" \ $coco_keyprovider_image \ /encrypt.sh \ -k "$KBS_KEY_B64" \ -i "$KBS_KEY_ID" \ -s dir:/oci/input -d dir:/oci/output # skopeo查看CoCo KeyProvider加密后的镜像描述 $skopeo_bin inspect dir:./oci/output | jq \ '.LayersData[0].Annotations["org.opencontainers.image.enc.keys.provider.attestation-agent"] | @base64d | fromjson' ``` * 可以看到预期的加密信息被应用 ``` { "kid": "kbs:///default/image_key/nginx", "wrapped_data": "45vUsa7RAs0qBIPvafvGvfApJPI0lBHApS04VFRLfyJJZnSu4Pccat248iS2ulsMkvxPhHWN6t+Jmwn4wRYhPN9O8eLNG8H7P8+pXVhCC7wS56Js/yXvtcGX2DSGj7nuIVEMj82FXaffjvN56PohjtugzTZxiNRWiin+pdYQYd3NiS9uyA5uQibkNL9cUopsThZSU75bxC2bwHCofeZjVKZpnZ3COhpf+LLnMBQLA+6PRYJqlexAimNNnF2tF0t8JBqf4QdH18c/Q5mcvoP8c7g=", "iv": "vbtzmoSV7SmvX4Yc", "wrap_type": "A256GCM" } ``` ## 把镜像密钥上传到KBS ```shell kubectl exec deploy/$kbs_deploy -n $kbs_namespace -c kbs \ -- mkdir -p "$kbs_resource_dir/$(dirname "$KBS_KEY_PATH")" cat "$KBS_KEY_FILE" | \ kubectl exec -i deploy/$kbs_deploy -n $kbs_namespace -c kbs \ -- tee "$kbs_resource_dir/${KBS_KEY_PATH}" > /dev/null ``` ## 上传加密镜像 ```shell $skopeo_bin copy dir:./oci/output "docker://${ENCRYPTED_IMAGE}" ``` ## 生成pod的yaml文件 ```shell cp $pod_yaml.template $pod_yaml sed -i "s!MARK_POD_NAME!$pod_name!g" $pod_yaml sed -i "s!MARK_KBS_POD_IP_ADDR!$kbs_pod_ip_addr!g" $pod_yaml sed -i "s!MARK_POD_RUNTIMECLASS!$pod_runtimeclass!g" $pod_yaml sed -i "s!MARK_POD_CONTAINER_IMAGE_ENCRYPTED!$pod_container_image_encrypted!g" $pod_yaml ``` ## 确定机密容器的启动度量值 ```shell # 先试着启动一下pod kubectl apply -f $pod_yaml # 计算启动度量值 pushd ../tools/measurement/ measure=$(./csv-calc-measurement.sh csv3 | \ grep "MEASUREMENT => " | sed "s/MEASUREMENT => //" | \ sed 's/^[[:space:]]*//') echo $measure popd # .../measurement # 删除pod kubeclt delete -f $pod_yaml popd # .../samples ``` ## 将度量值更新到KBS微服务系统中rvps中 ```shell pushd $HOME/workspace/CoCo/trustee-operator/config/samples/microservices/hygon/ # 首先也更新一下KBS微服务系统中的as策略引擎，比如： ## measurement必须与rvps中的一致 ## 容器所处的机密虚拟机policy中必须有csv3,nodbg,es等比特 # 以上这些示例均在$HOME/workspace/CoCo/trustee-operator/config/samples/microservices/hygon/dbg-attestation-policy.rego中有所体现 ./tool-operator-on-kbs-as-rvps.sh as "tee" # 把上面计算的机密容器启动度量值添加到rvps的json参考值文件中 cat > dbg-reference-values.json < 本章节主要是测试kata机密容器启动过程中验证cosign签名过的镜像签名，如果镜像签名验签通过，机密容器则可以成功启动并运行。 > > [测试脚本](samples/test-signing.sh)大致包含了测试的流程。 ## 提前下载、安装cosign程序 ```shell wget https://github.com/sigstore/cosign/releases/download/v2.2.1/cosign-linux-amd64 chmod +x cosign-linux-amd64 export cosign_bin=$(pwd)/cosign-linux-amd64 ``` ## 制作签名镜像 ```shell pushd $HOME/workspace/CoCo/deployment/samples/ export kbs_namespace="trustee-operator-system" export kbs_deploy="trustee-deployment" export kbs_pod_ip_addr="$(kubectl get pods -n $kbs_namespace -o wide | \ grep $kbs_deploy | \ sed "s/^.* \([0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\) .*$/\1/g" )" export kbs_resource_dir="/opt/confidential-containers/kbs/repository" export pod_yaml=signing.yaml export pod_name="nginx" export pod_runtimeclass="kata-qemu-csv3" export pod_container_image_unsigned="${your_unsigned_image}" export pod_container_image_signed="${your_signed_image}" export KBS_KEY_PATH="default/cosign-key/1" export KBS_SEC_POLICY_PATH="default/security-policy/test" export UNSIGNED_IMAGE="${your_unsigned_image}" export SIGNED_IMAGE="${your_signed_image}" # 生成cosign公私钥对 export output_dir=$(pwd)/test-cosign-signing mkdir -p $output_dir pushd $output_dir rm -rf cosign.key cosign.pub # output: cosign.key, cosign.pub COSIGN_PASSWORD="just1testing2password3" $cosign_bin generate-key-pair popd # 上传镜像并对镜像签名 export dockerfile=Dockerfile.test-signing cp $dockerfile.in $dockerfile sed -i "s!MARK_UNSIGNED_IMAGE!${UNSIGNED_IMAGE}!g" \ $dockerfile sudo docker build \ -t ${SIGNED_IMAGE} \ -f $dockerfile \ . docker push ${SIGNED_IMAGE} $cosign_bin sign --key $output_dir/cosign.key ${SIGNED_IMAGE} ``` ## 上传公钥数据和安全规则文件到KBS ```shell # 上传用于验证镜像签名的公钥到KBS kubectl exec deploy/$kbs_deploy -c kbs -n $kbs_namespace \ -- mkdir -p "${kbs_resource_dir}/$(dirname "$KBS_KEY_PATH")" cat $output_dir/cosign.pub | \ kubectl exec -i deploy/$kbs_deploy -c kbs -n $kbs_namespace \ -- tee "${kbs_resource_dir}/${KBS_KEY_PATH}" > /dev/null cat > security-sig-policy.json < " | sed "s/MEASUREMENT => //" | \ sed 's/^[[:space:]]*//') echo $measure popd # .../measurement # 删除pod kubeclt delete -f $pod_yaml popd # .../samples ``` ## 将度量值更新到KBS微服务系统中rvps中 ```shell pushd $HOME/workspace/CoCo/trustee-operator/config/samples/microservices/hygon/ # 首先也更新一下KBS微服务系统中的as策略引擎，比如： ## measurement必须与rvps中的一致 ## 容器所处的机密虚拟机policy中必须有csv3,nodbg,es等比特 # 以上这些示例均在$HOME/workspace/CoCo/trustee-operator/config/samples/microservices/hygon/dbg-attestation-policy.rego中有所体现 ./tool-operator-on-kbs-as-rvps.sh as "tee" # 把上面计算的机密容器启动度量值添加到rvps的json参考值文件中 cat > dbg-reference-values.json < 自
> https://gitee.com/hanliyang-kata-coco/trustee.git @tag=csv-verifier-fetch-cert-chain
> https://gitee.com/hanliyang-kata-coco/guest-components.git @tag=csv-attester-remove-online-cert-chain
> 开始，用于验证 给report签名的背书密钥 的证书链不再从Attestation-Agent（AA）中在线下载，为了保持结构兼容，AA只会把负载中的HSK_CEK部分填充为全0；Attestation-Service（AS）在验证report之前，会优先从本地/opt/hygon/csv/hsk_cek/${your_hw_chip_id}/hsk_cek.cert读取HSK、CEK（HSK、CEK用于证书链验证，HRK证书作为信任根已经内嵌于AS中），如果本地读取不到，则从海光KDS服务器下载芯片对应的HSK、CEK证书。 ## 测试AS从KDS服务器下载HSK、CEK验证证书链 * 直接参考
[验证远程认证功能](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/README.md#%E9%AA%8C%E8%AF%81%E8%BF%9C%E7%A8%8B%E8%AE%A4%E8%AF%81%E5%8A%9F%E8%83%BD)
重新执行一遍就行，如果pod运行成功，则表示功能正常。 ## 测试AS从服务的本地读取HSK、CEK验证证书链 * 可以参考以下任意一个章节进行实验：
[验证远程认证功能](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/README.md#%E9%AA%8C%E8%AF%81%E8%BF%9C%E7%A8%8B%E8%AE%A4%E8%AF%81%E5%8A%9F%E8%83%BD)
[验证镜像加密功能](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/README.md#%E9%AA%8C%E8%AF%81%E9%95%9C%E5%83%8F%E5%8A%A0%E5%AF%86%E5%8A%9F%E8%83%BD)
[验证镜像签名功能](https://gitee.com/hanliyang-kata-coco/deployment/blob/master/README.md#%E9%AA%8C%E8%AF%81%E9%95%9C%E5%83%8F%E7%AD%BE%E5%90%8D%E5%8A%9F%E8%83%BD)
但请注意，在`kubectl apply -f $pod_yaml`启动pod之前，对KBS微服务系统中的AS容器执行以下操作。 ```shell kubectl exec deploy/trustee-deployment -n trustee-operator-system \ -c as -- mkdir -p /opt/hygon/csv/hsk_cek/${your_hw_chip_id} cat ${your_hw_hsk_cek_file} | kubectl exec -i deploy/trustee-deployment \ -n trustee-operator-system -c as -- tee /opt/hygon/csv/hsk_cek/${your_hw_chip_id}/hsk_cek.cert ``` > 上述${your_hw_chip_id}可以通过以下命令获取到 ```shell sudo /path/to/hag general chip_id ``` > 上述${your_hw_hsk_cek_file}可以通过以下命令获取到 ```shell sudo /path/to/hag csv export_cert_chain ls hsk_cek.cert ```