在机密 GKE 节点中访问 vTPM 和证明信息

在机密 Google Kubernetes Engine 节点上运行的工作负载可以访问和使用平台完整性和安全功能，例如虚拟可信平台模块 (vTPM) 和机密计算证明报告。本文档向安全工程师展示了如何使 vTPM 和基于硬件的设备对 GKE 工作负载可见，以执行远程证明、Secret 密封和随机数生成等任务。

您应该已经熟悉以下资源：

您使用的具体机密计算技术取决于贵组织的威胁模型和安全要求。如需了解详情，请参阅机密计算技术。

机密计算任务

您可以从在机密 GKE 节点上运行的 Pod 访问 vTPM 和硬件模块。您可以使用这些模块执行加密操作，例如密钥密封或远程证明。用于执行这些任务的具体模块取决于节点使用的机密计算技术，如下所示：

  • Secret 密封：在所有机密计算技术中，工作负载都可以使用安全强化型虚拟机的 vTPM 作为 Secret 密封的信任根。

  • 远程证明：工作负载可以使用以下模块之一进行远程证明：

    • AMD SEV：安全强化型虚拟机的 vTPM。
    • AMD SEV-SNP：基于硬件的 AMD 安全处理器。
    • Intel TDX：基于硬件的 Intel TDX 模块。

    如需详细了解远程证明在每种机密计算技术中的运作方式，请参阅证明者架构和证据。

准备工作

在开始之前，请确保您已执行以下任务：

  • 启用 Google Kubernetes Engine API。
    • 启用 Google Kubernetes Engine API
  • 如果您要使用 Google Cloud CLI 执行此任务，请安装并初始化 gcloud CLI。如果您之前安装了 gcloud CLI，请通过运行 gcloud components update 命令来获取最新版本。较早版本的 gcloud CLI 可能不支持运行本文档中的命令。

要求

满足以下条件时，您可以使用机密 GKE 节点：

  • 集群和节点池必须运行以下版本之一，具体取决于您要访问的机密计算模块：

    • vTPMs：任何 GKE 版本。
    • 基于 AMD SEV-SNP 硬件的设备：GKE 1.33.5-gke.1350000 版及更高版本，或 1.34.1-gke.2037000 版及更高版本。
    • 基于 Intel TDX 硬件的设备：GKE 1.33.5-gke.1697000 版及更高版本，或 1.34.1-gke.2909000 版及更高版本。

  • 节点池必须位于具有相应机器类型的 Compute Engine 位置。如需详细了解区域可用性，请参阅机器类型、CPU 和可用区。

  • 节点必须使用 Container-Optimized OS 节点映像。

安装设备插件

为了使 GKE Pod 可以看到完整性和安全性信息，您需要安装设备插件。如需使用 DaemonSet 安装插件，请按以下步骤操作：

  1. 连接到集群：

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    替换以下内容：

    • CLUSTER_NAME：您的集群的名称。
    • CONTROL_PLANE_LOCATION：集群控制平面所在的区域或可用区，例如 us-central1 或 us-central1-a。

  2. 创建 cc-device-plugin DaemonSet：

    kubectl create -f https://raw.githubusercontent.com/google/cc-device-plugin/main/manifests/cc-device-plugin.yaml

创建 DaemonSet 后，机密 GKE 节点上的任何机密计算设备都会对在这些节点上运行的 Pod 可见。

从 Pod 访问机密计算设备

创建用于安装设备插件的 DaemonSet 后，您可以从 Pod 访问 vTPM 和基于硬件的设备，这与您在 Kubernetes 中请求其他扩展资源的方式类似。以下各部分介绍了如何从任何 Pod 访问 vTPM，以及如何在 AMD SEV-SNP 和 Intel TDX 节点中访问基于硬件的模块。

从 Pod 访问 vTPM

如需从在机密 GKE 节点上运行的任何 Pod 访问安全强化型虚拟机的 vTPM，请将 google.com/cc 设备添加到容器资源限制。以下步骤请求访问示例 Pod 中的 vTPM：

  1. 将以下 Pod 清单另存为 example-vtpm-pod.yaml：

    apiVersion: v1
kind: Pod
metadata:
name: my-vtpm-pod
spec:
containers:
- name: test-vtpm
  image: ubuntu
  command: ["/bin/sh", "-c", "ls -l /dev/tpmrm0; sleep 3600"]
  ports:
  - containerPort: 8080
    name: http
  resources:
    limits:
      google.com/cc: 1

  2. 创建 Pod：

    kubectl apply -f example-vtpm-pod.yaml

    Pod 获取对 /dev/tpmrm0 设备的访问权限。

  3. 如需验证 Pod 是否可以访问 vTPM，请检查 Pod 日志：

    kubectl logs my-vtpm-pod

    如果输出包含文件信息，则表示 Pod 可以访问设备。

您可以通过应用代码与设备进行互动。例如，您可以使用 Go-TPM 库与 vTPM 通信并执行密封等任务。如果您使用 AMD SEV，还可以使用 vTPM 对机密虚拟机实例执行远程证明。

从 Pod 访问基于硬件的模块

如果您使用 AMD SEV-SNP 或 Intel TDX，还可以通过在容器资源限制中指定相应的选择器，在 Pod 中访问相应的基于硬件的模块。您必须使用这些模块对使用 AMD SEV-SNP 和 Intel TDX 的节点执行远程证明，因为 vTPM 不是这些技术中测量的信任根。

以下步骤展示了如何请求访问 AMD 安全处理器或 Intel TDX 模块：

  1. 保存以下示例 Pod 之一：

    • 申请 AMD SEV-SNP 设备：

      apiVersion: v1
kind: Pod
metadata:
  name: snp-test-pod
spec:
  containers:
  - name: test-container
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "Checking for SEV-SNP device..."
        ls -l /dev/sev-guest
        echo "SNP container started successfully"
        sleep 3600
    resources:
      limits:
        amd.com/sev-snp: "1"
      requests:
        amd.com/sev-snp: "1"
  nodeSelector:
    cloud.google.com/gke-confidential-nodes-instance-type: SEV_SNP

    • 请求 Intel TDX 设备：

      apiVersion: v1
kind: Pod
metadata:
  name: tdx-test-pod
spec:
  containers:
  - name: test-container
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "Checking for TDX device..."
        ls -l /dev/tdx*
        echo "TDX container started successfully"
        sleep 3600
    resources:
      limits:
        intel.com/tdx: "1"
      requests:
        intel.com/tdx: "1"
  nodeSelector:
    cloud.google.com/gke-confidential-nodes-instance-type: TDX

  2. 创建 Pod：

    kubectl create -f PATH_TO_POD_MANIFEST

    将 PATH_TO_POD_MANIFEST 替换为您保存的 Pod 清单文件的路径。

    Pod 可访问以下任一设备：

    • /dev/sev-guest（适用于 AMD SEV-SNP）。
    • /dev/tdx_guest（适用于 Intel TDX）。

  3. 如需验证 Pod 是否可以访问设备，请检查 Pod 日志：

    kubectl logs POD_NAME

    将 POD_NAME 替换为您在上一步中部署的示例 Pod 的名称。

    如果输出包含文件信息，则表示 Pod 可以访问设备。

后续步骤