這是一項實驗性功能，僅供評估和測試之用，可能會變更，恕不另行通知。

建立機密容器

瞭解如何在 Red Hat OpenShift on IBM Cloud 叢集中安裝和使用機密容器（也稱為 Kata Containers 或 OpenShift Sandboxed Containers）。

什麼是機密容器？

保密容器可為敏感的工作負載提供安全的執行環境，但又可讓您繼續在現有的工作流程中工作。

IBM Cloud 的機密容器實作利用對等 Pod，將 Red Hat OpenShift Pod 的功能擴充到與 Worker 節點分離的 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 ' Operator Update Information Checker '。
在安裝操作員視窗中，您可以保留預設選擇，然後按一下安裝。
等待安裝完成。按一下 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 作業系統，以及在 Confidential Virtual Machine (CVM) 中實體容器所需的軟體。

作業系統中的所有設定與已安裝套件均維持預設的 Red Hat 值。然而，IBM Cloud 的VSI需要 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 建立另一個機密容器，請按一下 Get sample API call 按鈕，然後複製 Curl 指令。

e. 點擊「建立自訂圖片」。
影像加入影像清單後，按一下影像名稱，然後選擇 IDs 索引標籤。接著，請記下該圖像識別碼以備後續使用。
請等待圖片狀態顯示為「可用」。
```
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 功能。

按一下 Infrastructure > Compute > SSH Keys。
建立 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 資源的限制。 Kubernetes pod 建構時，每個對等 pod 會消耗工作節點上約 250m CPU 和 120Mi 記憶體，即使實際工作負載是在獨立的 VSI 中執行。如需相關資訊，請參閱常見問題。

應用 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 安裝完成並開始啟動 daemonsets 時，您可以監控進度。

您可以在 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`:Kata 安裝正在進行中。
    - `installed`:Kata 已成功安裝在節點上。
    - `waiting_for_reboot`:節點必須重新開機才能完成安裝或解除安裝。
    - `waiting_to_uninstall`:Kata 卸載在節點上排成佇列。
    - `uninstalling`:Kata 卸載正在進行中。
    - `uninstalled`:Kata 已從節點成功卸載。

當標籤更新並處於 waiting_for_reboot 狀態時，逐一重新啟動每個 Worker 節點。

當您執行 oc get nodes 且每個 Worker 節點都處於 installed 狀態時，安裝就完成了。

監控和調整同級 pod 限制

安裝完成後，您可以監控對等 pod 的容量，並在需要時調整 PEERPODS_LIMIT_PER_NODE 設定。

檢查所有 Worker 節點目前的對等 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'

檢查每個 Worker 節點上已分配的資源：

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. 重新啟動 Cloud API Adapter daemonset。

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：設定信任授權

認證是機密容器的重要部分。您必須驗證供應鏈程式碼的安全性，確保在容器中執行的程式碼沒有被修改。您可以利用 Intel TDX 晶片和 key-broker-service 通訊協定。 podvm 的映像中已有可運作的 TDX 驅動程式碼和 kbs_client。但您必須在 INITDATA 中設定信託人詳細資訊。

選擇信託人。機密容器的信託人有許多選擇。
- 為了開發目的，您可能會在上面啟動 VM 為受託人。
- 對於生產級服務，您可能會使用 Intel Trust Authority。
如果您選擇 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 daemonset。此 Cloud API Adapter daemonset 用於與 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 時，會顯示 Running（執行中 ）狀態。如果 VSI 似乎卡在「開始」狀態，請檢查記錄是否有問題。

a. 取得 Pod 的名稱。
```
oc get pods
```
b. 取得其中一個 Cloud API Adapter 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>
    ```
- Cloud API Adapter 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，這會刪除為 Pod 部署的 VSI。
```
oc delete -f pod.yaml
```
若您將先前設定的 ConfigMaps 變更為無效配置，或相關憑證已被移除，軟體將無法完成移除資源的 API 呼叫，屆時必須手動執行移除作業。手動移除僅適用於此情境，因為您可能需要建立新的 OpenShift 叢集或替換工作節點。
刪除 Kata 設定。 kata-runtime-settings.yaml 從工人身上移除 Kata，您可以觀看標籤的更新。

a. 監控節點標籤，直到它們處於 waiting_for_reboot 狀態。

b. 逐一重新啟動 Worker，以完成卸載 Worker 節點上的 Kata。

c. 如果有其他工作負載在此群集上執行，請封鎖 Worker，排空它，然後再重新啟動。

d. 重新開機後，請等待 kata-runtime-settings.yaml 刪除完成後再繼續下一步。有一些進程必須在重新開機後完成解除安裝。

如果 kata-runtime-settings.yaml 資源無法刪除，請勿繼續。
刪除 ConfigMaps。

卸載操作員

移除工作負載後，您可以解除安裝 OpenShift Sandboxed Containers Operator。

從 OperatorHub, 卸載操作員。
確認 openshift-sandboxed-containers-operator 命名空間中沒有剩餘的資源。
刪除名稱空間。