这是一项试验性功能，用于评估和测试目的，可能会更改，恕不另行通知。

创建保密集装箱

了解如何在 Red Hat OpenShift on IBM Cloud 集群中安装和使用机密容器（也称为 Kata 容器或 OpenShift Sandboxed Containers）。

什么是保密集装箱？

保密容器可为敏感工作负载提供安全的运行环境，但允许您继续在现有工作流中工作。

IBM Cloud 的机密容器实现利用对等 pod 将 Red Hat OpenShift pod 的功能扩展到与工作节点分开的 VSI 中。这一扩展创建了一个超越传统 Kubernetes 和 OpenShift 的可信执行环境。

了解更多信息：

回顾使用保密容器的原因。
查看常问问题，了解保密容器。

先决条件

创建或选择使用 Red Hat OpenShift on IBM Cloud 群集时，该群集必须满足以下要求：
- 集群必须位于支持 TDX 虚拟服务器实例(VSI)的区域中。
- 群集必须有一个公共接口，或者您可以通过 VPN 连接到其环境。
- 为了允许集群与任何使用机密容器创建的 VSI 通信，必须创建一个名为“机密容器”的安全组。kube-CLUSTER_ID 针对集群。
如有必要，启用 OperatorHub. 有时，出于安全原因，集群会禁用 OperatorHub。

步骤 1：安装操作员

安装 OpenShift Sandboxed Containers Operator，以管理集群中机密容器的生命周期。

打开群组仪表板。
单击 OpenShift 网络控制台 > 操作员 >。OperatorHub.
搜索 OpenShift sandboxed containers Operator 并点击磁贴。
单击“安装”获取受支持的稳定版 OpenShift Sandboxed Containers Operator（版本 1.10.3 ）。有关支持的 OpenShift 版本，请参阅 Red Hat 的“操作员更新信息检查器”。
在“安装操作员”窗口中，可以保留默认选择并单击“安装”。
等待安装完成。单击 " View installed Operators in Namespace openshift-sandboxed-containers-operator " 链接，等待状态显示为 " Succeeded "。在等待期间，您可以完成下一步设置 CLI。

步骤 2：设置 CLI

开始之前，您可以完成这些步骤来设置 CLI，也可以使用 IBM Cloud shell 运行命令。

安装 IBM Cloud 命令行。
安装 ks 和 oc CLI 工具。

登录到 IBM Cloud CLI。

ibmcloud login --apikey API_KEY -g RESOURCE_GROUP

列出账户中的群集，并复制要用于下一步的群集 ID。
```
ibmcloud ks cluster ls
```
运行 config 命令。
```
ibmcloud ks cluster config --cluster CLUSTER_ID --admin --endpoint link
```
在你的主目录中，会创建一个 .kube 文件夹，并存储与该群集通信的信息。
通过查看群集中工作节点的详细信息，确认 oc 命令运行正常。
```
oc get nodes
```
设置命名空间项目，这样就不必在以后的命令中包含命名空间。
```
oc project openshift-sandboxed-containers-operator
```
可选探索命名空间。
```
oc get all
```
例如，在 pod 列表中，名为 pod/controller-manager-<id> 的控制器管理器管理操作员内的微服务。
安装 is CLI 工具。

第 3 步：导入对等 pod 映像

OpenShift Sandboxed Containers Operator 会在对等 pod 内启动一个特殊的操作系统，该操作系统必须导入到您的 IBM Cloud 账户中。将工作负载部署到机密容器时需要使用该操作系统。

对等 pod 映像包含完整的 Red Hat Enterprise Linux (RHEL) 9.6 操作系统，以及在机密虚拟机 (CVM) 中实例化容器所需的软件。

操作系统中的所有配置和已安装软件包均保持默认的 Red Hat 值。然而，IBM Cloud 的VSIs需要 cloud init 才能运行。在脚本中，cloud init 在完成构建 podvm 后就无法卸载，这是它与源图像的主要区别。

开始之前：

验证版本兼容性。该图像支持以下版本。

OpenShift 沙箱容器操作员版本 1.10.3
OpenShift 版本 4.19, 4.18, 4.17，和 4.16 集群

导入对等 pod 映像：

运行该 image-create 命令。

# Note IMAGE_NAME is a placeholder variable. Image names do not support capitalization.
ibmcloud is image-create "IMAGE_NAME" --file cos://us-south/podvm-image/rhel9-podvm-latest.qcow2  --os-name red-9-amd64

打开计算映像。
点击创建+ 图标，选择具备TDX功能的VSI所在区域，并填写必填字段。

a. 对于图像源，选择 Cloud Object Storage.

b. 选择“通过图像文件定位 URL”选项卡，并在图像 URL 中输入 cos://us-south/podvm-image/rhel9-podvm-latest.qcow2。

c. 操作系统请选择 Red Hat Enterprise Linux > red-9-amd64.

d. 可选：如果以后要从 API 创建另一个具有相同详细信息的机密容器，请单击获取示例 API 调用按钮并复制 Curl 命令。

e. 点击 “创建自定义图片”。
图像添加到图像列表后，单击图像名称并选择 ID 选项卡。然后，记下图像ID 以便后续使用。
请等待图片状态变为“可用”。
```
ibmcloud is image IMAGE_NAME
```
当有新版本的图像时，重复这些步骤。

第 4 步：创建 API 密钥或可信配置文件

在启动安全工作负载时，保密容器需要一个凭据才能通过 kata-remote 实例化对等 pod。该凭证必须是有效的 API 密钥或受信任的配置文件，并具有在您的账户中创建 VSI 的权限。

如果要测试机密容器，可以使用 API 密钥。如果使用 Secrets Manager，则必须设置受信任的配置文件。

API密钥 （来自用户界面）
1. 从 IBM Cloud 控制面板，单击管理 > 访问 (IAM) > API 密钥。
2. 单击创建。
3. 请妥善保存该密钥，因为以后无法从该页面检索该密钥。
通过命令行界面获取的API密钥。

运行以下命令，并将输出结果保存下来。
```
ibmcloud iam api-key-create KEY_NAME
```

可信概要文件

打开可信配置文件仪表板。

创建一个受信任的配置文件并授予该配置文件从 OpenShift 创建虚拟服务器所需的权限。

a. 创建可信档案。

ibmcloud iam trusted-profile-create <NAME> [--description <DESCRIPTION>]

b. 允许 openshift-sandboxed-containers-operator 中的资源使用受信任配置文件。

ibmcloud iam trusted-profile-rule-create PROFILE_NAME_OR_ID --name RULE_NAME --type Profile-CR --conditions claim:namespace,operator:EQUALS,value:openshift-sandboxed-containers-operator --cr-type ROKS_SA

c. 允许访问 VPC 基础设施服务 (is)。

允许访问账户中的所有资源：

ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile>  --roles Editor,Writer --service-name is

要允许访问特定资源组：

ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile> --roles Viewer [--resource-group-id <resource group>]

步骤 5：创建 SSH 密钥（可选）

在测试集群中，准备一个 SSH 密钥可能对排除故障和查看日志很有帮助。在生产集群中，您可能不希望启用 SSH 功能。

单击基础架构 > 计算 > SSH 密钥。
创建 SSH 密钥并记下 SSH 密钥 ID。

步骤 6：配置机密容器

安装操作员后，创建 ConfigMaps，允许 Kata 处理 IBM Cloud 账户中的工作负载。

创建一个目录来存放这些文件。
```
mkdir <directory-name>
```
切换到目录。
```
cd <directory-name>
```
复制以下环境变量：API 密钥、受信任配置文件 ID、群集名称、PodVM 映像 ID、SSH 密钥 ID 和 VPC ID（可选）。

可选项：您可以将它们存储在新目录下的 Shell 脚本中，以便以后再次设置。示例： <directory-name>/env-vars.sh

a. 收集以下变量的值，并更新脚本中的值。
- 对于 CLUSTER_NAME，在群集列表中打开群集的详细信息并复制名称。
- 可选：对于 VPC_ID，在同一页面的群集详细信息部分，可以单击 vpc 名称打开 VPC 的详细信息，并复制 VPC ID 字段。
- 对于 PODVM_IMAGE_ID，请使用您为对等 pod 图像保存的图像 ID。
- 如果使用的是 API 密钥，可以删除 IBMCLOUD_TRUSTED_PROFILE_ID 行。
- 如果使用的是受信任的配置文件，则可以删除 IBMCLOUD_API_KEY 行。
- 如果没有设置 SSH 密钥，可以删除 SSH_KEY_ID 行。
```
export IBMCLOUD_API_KEY=<your API key>
export IBMCLOUD_TRUSTED_PROFILE_ID="<your Trusted Profile ID>"
export CLUSTER_NAME=<cluster-name-region-flavor>
export PODVM_IMAGE_ID=<PodVM image ID provided by IBM or a custom-built image>
export SSH_KEY_ID=<SSH key ID to be used by the peer pod VSI>
export VPC_ID=<Optional: the VPC that your Openshift cluster is in>
```
b. 如果将变量存储在 Shell 脚本中，请运行该脚本。示例：
```
sh env-vars.sh
```

运行命令创建 feature-gates.yaml ConfigMap。

cat > feature-gates.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: osc-feature-gates
  namespace: openshift-sandboxed-containers-operator
data:
  deploymentMode: "DaemonSetFallback" # or DaemonSet to force it
  confidential: "true"
  layeredImageDeployment: "false"
EOF

应用 ConfigMap。
```
oc apply -f feature-gates.yaml
```

运行命令创建 peer-pods-secret.yaml。从 stringData 部分删除任何你需要的可选环境变量。

cat > peer-pods-secret.yaml <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: peer-pods-secret
  namespace: openshift-sandboxed-containers-operator
type: Opaque
stringData:
  # either IBMCLOUD_API_KEY or IBMCLOUD_IAM_PROFILE_ID must be set
  # if you specify both the IBMCLOUD_API_KEY will be used
  # IBMCLOUD_IAM_ENDPOINT is optional
  IBMCLOUD_API_KEY: "$IBMCLOUD_API_KEY"
  IBMCLOUD_IAM_ENDPOINT: "https://iam.cloud.ibm.com/identity/token"
  IBMCLOUD_IAM_PROFILE_ID: "$IBMCLOUD_TRUSTED_PROFILE_ID"
EOF

将密钥应用到集群上。
```
oc apply -f peer-pods-secret.yaml
```

运行命令创建 peer-pods-cm.yaml ConfigMap。从 data 部分删除未设置的可选环境变量。

cat > peer-pods-cm.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: peer-pods-cm
  namespace: openshift-sandboxed-containers-operator
data:
  CLOUD_PROVIDER: "ibmcloud"
  IBMCLOUD_PODVM_IMAGE_ID: "$PODVM_IMAGE_ID"
  IBMCLOUD_PODVM_INSTANCE_PROFILE_LIST: "bx3dc-2x10"
  IBMCLOUD_PODVM_INSTANCE_PROFILE_NAME: "bx3dc-2x10"
  IBMCLOUD_RESOURCE_GROUP_ID: "$(ibmcloud is vpc "$VPC_ID" -json | jq -r .resource_group.id)"
  IBMCLOUD_SSH_KEY_ID: "$SSH_KEY_ID"
  IBMCLOUD_VPC_ID: "$VPC_ID"
  IBMCLOUD_VPC_SG_ID: "$(ibmcloud ks security-group ls --cluster $CLUSTER_NAME -json | jq -r '.[] | select(.type == "cluster") | .id')"
  CLOUD_CONFIG_VERIFY: "false"
  CRI_RUNTIME_ENDPOINT: "/run/cri-runtime/containerd.sock"
  ENABLE_CLOUD_PROVIDER_EXTERNAL_PLUGIN: "false"
  VXLAN_PORT: ""
  TUNNEL_TYPE: ""
  INITDATA: ""
  PEERPODS_LIMIT_PER_NODE: "10"
EOF

PEERPODS_LIMIT_PER_NODE 设置可控制每个工作节点可调度的最大对等 pod VSI 数量。默认值为 10。您可以根据 Worker 节点的容量增加该值，但请注意，您还受到 Kubernetes pod 限制（对于 16x64 Worker，每个节点有 110 个 pod）和 Worker 节点上可用 CPU 资源的限制。尽管实际工作负载在单独的 VSI 中运行，但每个对等 pod 在 Kubernetes pod 结构的工作节点上消耗大约 250m CPU 和 120Mi 内存。有关更多信息，请参阅常见问题。

应用 ConfigMap。
```
oc apply -f peer-pods-cm.yaml
```

运行命令创建 kata-runtime-settings.yaml KataConfig。

cat > kata-runtime-settings.yaml <<EOF
apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
  name: kata-runtime-settings
  namespace: openshift-sandboxed-containers-operator
spec:
  enablePeerPods: true
  logLevel: info
 #checkNodeEligibility: true
 #kataConfigPoolSelector:
 #  matchLabels:
 #    <label_key>: '<label_value>'
EOF

应用 KataConfig。
```
oc apply -f kata-runtime-settings.yaml
```

随着 Kata 的安装和守护进程的启动，您可以监控安装进度。

您可以在 OperatorHubopenshift-sandboxed-containers-operator KataConfig 正在进行中。
您可以运行以下命令，查看标签是否根据当前安装状态进行了更新。

    oc get nodes --output yaml|egrep "kata-ds-rpm-install|ibm-cloud.kubernetes.io/worker-id"
    ```
    可能的状态

    - `waiting_to_install`:节点上的 Kata 安装正在排队。
    - `installing`:卡塔安装正在进行中。
    - `installed`:节点上已成功安装 Kata。
    - `waiting_for_reboot`:节点必须重新启动才能完成安装或卸载。
    - `waiting_to_uninstall`:节点上的 Kata 卸载处于队列中。
    - `uninstalling`:卡塔卸载正在进行中。
    - `uninstalled`:Kata 已成功从节点卸载。

当标签更新并处于 waiting_for_reboot 状态时，逐个重新启动每个工作节点。

当运行 oc get nodes 且每个工作节点都处于 installed 状态时，安装完成。

监控和调整同行 pod 限制

安装后，您可以监控对等 pod 的容量，并根据需要调整 PEERPODS_LIMIT_PER_NODE 设置。

检查所有工作节点上当前的对等 pod 数量限制：

oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'

检查每个工作节点上分配的资源：

for n in $(oc get nodes -o name); do
  echo "=== $n ==="
  oc describe "$n" | sed -n '/Allocated resources:/,/Events:/p'
done

计算当前运行的对等 pod 的数量：

oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"' | wc -l

安装后要增加 PEERPODS_LIMIT_PER_NODE 值：

a. 更新 ConfigMap。

oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
  --type merge \
  -p '{"data":{"PEERPODS_LIMIT_PER_NODE":"24"}}'

b. 重新启动云 API 适配器守护进程集。

oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds

c. 验证新的限制是否已应用。

oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'

步骤 7：配置信任授权

认证是保密集装箱的重要组成部分。您必须验证供应链代码的安全性，确保在容器中运行的代码未被修改。您可以利用英特尔 TDX 芯片和 key-broker-service 协议。 podvm 的映像中已经包含了可正常工作的 TDX 驱动程序代码和 kbs_client。不过，您必须在 INITDATA 中配置受托人的详细信息。

选择受托人。保密集装箱托管有多种选择。
- 出于开发目的，您可以在其上启动 VM 为受托人。
- 对于生产级服务，您可以使用英特尔信任授权。
如果出于开发目的为受托管理人选择了 VM，请完成以下配置步骤。

a. 将受托管理机构的 IP 地址插入以下脚本并运行，以设置 INITDATA 变量。
```
export KBS_SERVICE_ENDPOINT="https://REPLACE_WITH_TRUSTEE_IP:8080"
export INITDATA=$(cat <<EOF | gzip | base64 -w0
algorithm = "sha256"
version = "0.1.0"
[data]
"aa.toml" = '''
[token_configs]
[token_configs.coco_as]
url = "$KBS_SERVICE_ENDPOINT"
[token_configs.kbs]
url = "$KBS_SERVICE_ENDPOINT"
'''
"cdh.toml"  = '''
socket = 'unix:///run/confidential-containers/cdh.sock'
credentials = []
[kbc]
name = "cc_kbc"
url = "$KBS_SERVICE_ENDPOINT"
'''
EOF
)
```
b. 请验证 $INITDATA 环境变量。
```
echo $INITDATA
```
c. 将变量值添加到 openshift-sandboxed-containers-operator 命名空间中的 peer-pods-cm.yaml ConfigMap。

d. 在 openshift-sandboxed-containers-operator 命名空间中重新启动 osc-caa-ds 守护进程。此云 API 适配器守护进程集用于与 IBM Cloud 通信。
```
oc rollout restart daemonset.apps/osc-caa-ds
```
e. 运行以下命令以查看 Pod。对于每个 osc-caa-ds-<id> pod，查看每个 pod 的 Age，以验证 pod 是否已重新启动。
```
oc get pods
```
如果 pod 没有重新启动，请删除 pod 以重新创建它。
```
oc delete pod/osc-caa-ds-<id>
```
再次查看豆荚。
```
oc get pods
```
f. 对 INITDATA 的每个工作量条目重复上述步骤。

（例如， INITDATA 值可作为注释应用于单个容器，启动的容器被配置为使用托管人。在测试新受托人或确保对 INITDATA 的更改不会破坏任何机密容器时，此注释会很有帮助。

注释示例：
```
apiVersion: v1
kind: Pod
  metadata:
    name: mypod
    annotations:
      io.katacontainers.config.runtime.cc_init_data: $INITDATA
spec:
  runtimeClassName: kata-remote
```

第 8 步：运行机密容器工作负载

将所有标签更新为 installed 后，在 pod.yaml 文件中使用 kata-remote 运行时类名部署工作负载。您可以将 Hello World 示例用作保密容器中的测试工作负载。

创建 pod.yaml 文件。

oc apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: helloworld
    version: v1
  name: helloworld
spec:
  containers:
  - name: helloworld
    image: docker.io/istio/examples-helloworld-v1:1.0
    ports:
    - containerPort: 5000
  runtimeClassName: kata-remote
EOF

在 Virtual Servers 列表中监控部署情况。创建 VSI 时，它会显示“运行”状态。如果 VSI 似乎卡在 “启动” 状态，请检查日志是否有问题。

a. 获取 pod 名称。
```
oc get pods
```
b. 获取云 API 适配器 pod 的日志并查找错误。
```
oc logs osc-caa-ds-<id>
```
运行以下命令来验证该 Pod。
```
oc describe pod/helloworld
```
要检查验证，请执行以下命令进入容器。
```
oc exec -it helloworld -- bash
```
然后，运行以下 curl 命令，从托管人处获取信息。
```
curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1
```
完成后，您可以退出容器。
```
exit
```

如果出现问题，请查看 openshift-sandboxed-containers-operator 命名空间中的日志。

控制器管理的 pod 日志：

    oc logs pod/controller-manager-<UNIQUE_ID>
    ```
- 云 API 适配器 pod 日志：

```sh {: pre}
    oc logs pod/osc-caa-ds-<UNIQUE_ID>
    ```
- 应用程序日志：取决于指定的位置。

现在，您的机密容器设置已完成！仍然需要帮助？查看故障排除情况。

删除工作负载和工具

如果完成这些步骤的顺序不对，可能会留下需要付费的资源，如 VSI。

删除工作负载

从群集中删除使用机密容器的工作负载。

a. 显示所有 pod。
```
oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"'
```
b. 删除 pod，从而删除为其部署的 VSI。
```
oc delete -f pod.yaml
```
若您将之前的 ConfigMaps 配置修改为无效设置，或凭据已被移除，则软件将无法完成删除资源的 API 调用，这些资源必须手动移除。手动移除仅适用于此场景，因为您可能需要创建新的 OpenShift 集群或替换工作节点。
删除卡塔配置。 kata-runtime-settings.yaml 从工人身上移除卡塔，您可以看到标签的更新。

a. 监控节点标签，直到它们处于 waiting_for_reboot 状态。

b. 逐个重启工人节点，完成卸载工人节点上的 Kata。

c. 如果该群集上正在运行其他工作负载，则应封锁该工作负载，将其耗尽，然后重新启动。

d. 重新启动后，等待 kata-runtime-settings.yaml 删除完成后继续下一步。有一些进程必须在重启后完成卸载。

如果 kata-runtime-settings.yaml 资源无法删除，请不要继续。
删除 ConfigMaps。

卸载操作员

移除工作负载后，可以卸载 OpenShift Sandboxed Containers Operator。

从 OperatorHub, 卸载操作器。
确认 openshift-sandboxed-containers-operator 命名空间中没有剩余资源。
删除名称空间。