これは評価およびテスト目的で利用できる実験的な機能であり、予告なく変更される場合があります。

機密容器の作成

Kata Containers または OpenShift Sandboxed Containers とも呼ばれる機密コンテナを Red Hat OpenShift on IBM Cloud クラスタにインストールして使用する方法を学ぶ。

機密容器とは何ですか？

機密コンテナは、機密性の高いワークロードにセキュアな実行環境を提供するが、既存のワークフロー内で作業を継続することができる。

IBM Cloud の機密コンテナの実装では、ピアポッドを活用して Red Hat OpenShift ポッドの機能をワーカーノードとは別の VSI に拡張している。この拡張機能により、従来の Kubernetes や OpenShift を超える信頼できる実行環境が構築される。

詳細はこちら:

機密容器を使用する理由を確認する。
機密容器についてはよくある質問。

前提条件

使用する Red Hat OpenShift on IBM Cloud クラスタを作成または選択する場合、そのクラスタは以下の要件を満たしている必要があります：
- クラスタは、 TDX Virtual Server Instances（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 」を参照してください。
Install Operator] ウィンドウでは、デフォルトの選択のまま[ Install] をクリックします。
インストールが完了するまで待ちます。 View installed Operators in Namespace openshift-sandboxed-containers-operator リンクをクリックし、ステータスが Succeeded になるのを待ちます。待っている間に、CLIをセットアップするための次のステップを完了できます。

ステップ2：CLIのセットアップ

開始する前に、CLIをセットアップするために以下の手順を完了するか、 IBM Cloud シェルを使用してコマンドを実行することができます。

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/controller-manager-<id> という名前のコントローラマネージャが、オペレータ内のマイクロサービスを管理します。
is CLIツールをインストールする。

ステップ3：ピアポッドイメージのインポート

OpenShift Sandboxed Containers Operatorは、ピアポッド内で特別なオペレーティングシステムを起動します。このオペレーティングシステムは、 IBM Cloud アカウントにインポートする必要があります。このオペレーティングシステムは、機密コンテナにワークロードをデプロイするために必要である。

ピアポッドイメージには、 Red Hat Enterprise Linux （RHEL） 9.6 オペレーティングシステムと、CVM（Confidential Virtual Machine）内でコンテナをインスタンス化するために必要なソフトウェアが含まれています。

オペレーティングシステム内のすべての設定およびインストール済みパッケージは、デフォルトの Red Hat 値のままです。ただし、 IBM Cloud のVSIは動作するためにが必要です cloud init。スクリプトでは、 cloud init は、 podvm のビルドが終了してもアンインストールされないようになっている。これは、ソースイメージとの重要な違いである。

始める前に

バージョンの互換性を検証する。このイメージは以下のバージョンに対応しています。

OpenShift サンドボックス化されたコンテナオペレータバージョン 1.10.3
OpenShift バージョン 4.19、 4.18、 4.17、 4.16 クラスタ

ピアポッドイメージをインポートするには

コマンド 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. Locate by image file URL タブを選択し、 Image URL に cos://us-south/podvm-image/rhel9-podvm-latest.qcow2 と入力する。

c. **オペレーティング・システムについては **Red Hat Enterprise Linux > red-9-amd64.

d. オプション：後で同じ詳細で API から別の機密コンテナを作成するには、[ サンプル API 呼び出しを取得 ] ボタンをクリックし、 Curl コマンドをコピーします。

e. 「 カスタム画像を作成 」をクリックします。
画像が画像リストに追加されたら、画像名をクリックし、 IDs タブを選択します。その後、後で使用するために画像ID をメモしてください。
画像のステータスが「 利用可能 」になるまでお待ちください。
```
ibmcloud is image IMAGE_NAME
```
新しいバージョンのイメージが利用可能になったら、これらの手順を繰り返します。

ステップ4：APIキーまたは信頼済みプロファイルの作成

機密コンテナは、安全なワークロードが起動されたときに、 kata-remote を介してピアポッドをインスタンス化するためにクレデンシャルを必要とする。このクレデンシャルは、有効なAPIキーか、アカウントでVSIを作成する権限を持つ信頼されたプロファイルでなければなりません。

機密コンテナをテストする場合は、APIキーを使用することができます。 Secrets Manager を使用している場合は、信頼済みプロファイルを設定する必要があります。

UIからの APIキー
1. IBM Cloud ダッシュボードから、［管理］＞［ アクセス（IAM） ］＞［ APIキー ］の順にクリックします。
2. 「作成」 をクリックします。
3. このキーは後でこのページから取り出すことはできないので、安全に保存してください。
CLIからの APIキー

次のコマンドを実行し、その出力を保存してください。
```
ibmcloud iam api-key-create KEY_NAME
```
トラステッド・プロファイル
1. 信頼済みプロファイルダッシュボードを開く。
2. 信頼済みプロファイルを作成し、そのプロファイルに、 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 Infrastructure Services (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：機密コンテナの設定

Operator のインストール後、 IBM Cloud アカウントで Kata がワークロードを処理できるように ConfigMaps を作成します。

ファイルを保存するディレクトリを作成してください。
```
mkdir <directory-name>
```
ディレクトリに切り替える。
```
cd <directory-name>
```
APIキー、信頼済みプロファイルID、クラスタ名、 PodVM イメージID、SSHキーID、およびVPC ID（オプション）の環境変数をコピーします。

オプション：新しいディレクトリのシェルスクリプトに保存して、後で再び設定することができます。例: <directory-name>/env-vars.sh

a. 以下の変数の値を収集し、スクリプトの値を更新する。
- CLUSTER_NAME、クラスタ・リストのクラスタの詳細を開き、名前をコピーする。
- オプション： VPC_ID、同じページのクラスタの詳細セクションで、 vpc 名をクリックしてVPCの詳細を開き、 VPC ID フィールドをコピーできます。
- PODVM_IMAGE_ID には、ピア・ポッド・イメージ用に保存したイメージ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. 変数をシェルスクリプトに保存した場合は、それを実行する。次に例を示します。
```
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 設定は、ワーカーノードごとにスケジュールできるピアポッドVSIの最大数を制御します。デフォルト値は10です。ワーカーノードの容量に応じてこの値を増やすことができますが、 Kubernetes のポッド制限（ 16x64 ワーカーの場合、ノードあたり 110 ポッド）と、ワーカーノードで利用可能な CPU リソースにも制約されることに注意してください。各ピアポッドは、実際のワークロードが別のVSIで実行されているにもかかわらず、 Kubernetes ポッド構築のためにワーカーノードで約 250m CPU と 120Mi メモリを消費します。詳しくは、FAQ を参照してください。
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`:Kata のアンインストールが進行中です。
    - `uninstalled`:Kataはノードから正常にアンインストールされました。

ラベルが更新され、 waiting_for_reboot の状態になったら、ワーカーノードを1つずつリブートする。

oc get nodes を実行し、各ワーカノードが installed の状態になれば、インストールは完了です。

ピアポッドの制限の監視と調整

インストール後、ピアポッドの容量を監視し、必要に応じて PEERPODS_LIMIT_PER_NODE の設定を調整することができます。

すべてのワーカーノードで、現在のピアポッドの制限をチェックします：

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

現在実行中のピアポッドの数をカウントする：

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 デーモンセットを再起動します。

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 デーモンセットを再起動する。この Cloud API Adapter デーモンセットは、 IBM Cloud と通信するために使用される。
```
oc rollout restart daemonset.apps/osc-caa-ds
```
e. 以下のコマンドを実行して、ポッドを表示します。 osc-caa-ds-<id> の各ポッドについて、各ポッドのエイジを見て、ポッドが再起動されたことを確認する。
```
oc get pods
```
ポッドが再起動しなかった場合は、ポッドを削除して再作成してください。
```
oc delete pod/osc-caa-ds-<id>
```
ポッドをもう一度見る。
```
oc get pods
```
f. INITDATA の各作業負荷エントリについて、これらの手順を繰り返す。

g. 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. ポッド名を取得します。
```
oc get pods
```
b. Cloud API Adapterポッドの1つのログを取得し、エラーを探します。
```
oc logs osc-caa-ds-<id>
```
次のコマンドを実行して、ポッドを確認してください。
```
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 ネームスペースのログを確認してください。

コントローラが管理するポッドのログ：

    oc logs pod/controller-manager-<UNIQUE_ID>
    ```
- Cloud API Adapter のポッドログ：

```sh {: pre}
    oc logs pod/osc-caa-ds-<UNIQUE_ID>
    ```
- アプリケーションログ：指定された場所による

これで機密コンテナのセットアップは完了です！引き続きヘルプが必要ですか? トラブルシューティングをチェックする

ワークロードとツールの削除

これらのステップを間違った順序で完了すると、VSIのような請求されるリソースが残ってしまう可能性があります。

ワークロードの削除

機密コンテナを使用するワークロードをクラスタから削除する。

a. すべてのポッドを表示します。
```
oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"'
```
b. ポッドを削除すると、そのポッドにデプロイされた VSI が削除されます。
```
oc delete -f pod.yaml
```
以前の ConfigMaps を無効な設定に変更した場合、または認証情報が削除された場合、ソフトウェアはリソースを削除するためのAPI呼び出しを完了できず、手動で削除する必要があります。このシナリオでは手動での削除のみを使用してください。新しい OpenShift クラスターの作成やワーカーの交換が必要になる可能性があるためです。
Kata の設定を削除します。 kata-runtime-settings.yaml 、作業員からカタを外す。ラベルが更新されるのを見ることができる。

a. ノードラベルが waiting_for_reboot の状態になるまで監視する。

b. Workerを1つずつ再起動して、Workerノード上のKataのアンインストールを完了します。

c. このクラスタ上で他のワークロードが動作している場合は、ワーカーをコード化し、排水してから再起動します。

d. 再起動後、 kata-runtime-settings.yaml 削除が完了するまで待ち、次のステップに進む。再起動後にアンインストールを完了しなければならないプロセスがある。

kata-runtime-settings.yaml リソースの削除に失敗した場合は続行しないこと。
ConfigMaps を削除してください。

オペレーターのアンインストール

ワークロードを削除したら、 OpenShift Sandboxed Containers Operator をアンインストールできます。

OperatorHub, からオペレータをアンインストールします。
openshift-sandboxed-containers-operator ネームスペースに残りのリソースがないことを確認する。
名前空間を削除します。