5.3. IBM Z および IBM LinuxONE への Confidential Containers のデプロイ

OpenShift sandboxed containers をデプロイした後、IBM Z® および IBM® LinuxONE に Confidential Containers をデプロイできます。

重要

IBM Z® および IBM® LinuxONE の Confidential Containers は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

クラスターの要件

Confidential compute attestation Operator をインストールするクラスターに Red Hat OpenShift Container Platform 4.15 以降がインストールされている。

次の手順を実行して、Confidential Containers をデプロイします。

Confidential compute attestation Operator をインストールします。
Trustee のルートを作成します。
Confidential Containers フィーチャーゲートを有効にします。
ピア Pod config map を更新します。
KataConfig カスタムリソース (CR) を削除します。
ピア Pod のシークレットを更新します。
KataConfig CR を再作成します。
Trustee 認証シークレットを作成します。
Trustee config map を作成します。
IBM Secure Execution (SE) ヘッダーを取得します。
SE 証明書とキーを設定します。
永続ストレージコンポーネントを作成します。
アテステーションポリシーを設定します。
1. 参照値を作成します。
2. アテスしたクライアントのシークレットを作成します。
3. リソースアクセスポリシーを作成します。
SE のアテステーションポリシーを作成します。
KbsConfig CR を作成します。
アテステーションプロセスを確認します。

5.3.1. Confidential compute attestation Operator のインストール

CLI を使用して、IBM Z® および IBM® LinuxONE に Confidential compute attestation Operator をインストールできます。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

trustee-namespace.yaml マニフェストファイルを作成します。
```
apiVersion: v1
kind: Namespace
metadata:
  name: trustee-operator-system
```
次のコマンドを実行して、trustee-operator-system namespace を作成します。
```
$ oc apply -f trustee-namespace.yaml
```

trustee-operatorgroup.yaml マニフェストファイルを作成します。

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: trustee-operator-group
  namespace: trustee-operator-system
spec:
  targetNamespaces:
  - trustee-operator-system

以下のコマンドを実行して Operator グループを作成します。
```
$ oc apply -f trustee-operatorgroup.yaml
```

trustee-subscription.yaml マニフェストファイルを作成します。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: trustee-operator
  namespace: trustee-operator-system
spec:
  channel: stable
  installPlanApproval: Automatic
  name: trustee-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: trustee-operator.v0.1.0

次のコマンドを実行して、サブスクリプションを作成します。
```
$ oc apply -f trustee-subscription.yaml
```
次のコマンドを実行して、Operator が正常にインストールされていることを確認します。
```
$ oc get csv -n trustee-operator-system
```
このコマンドが完了するまでに数分かかる場合があります。

次のコマンドを実行してプロセスを監視します。

$ watch oc get csv -n trustee-operator-system

出力例

NAME                      DISPLAY                        PHASE
trustee-operator.v0.1.0   Trustee Operator  0.1.0        Succeeded

5.3.2. Trustee のルートの作成

Trustee のエッジ TLS 終端を使用してセキュアなルートを作成できます。外部の Ingress トラフィックは HTTPS としてルーター Pod に到達し、HTTP として Trustee Pod に渡されます。

前提条件

Confidential Containers フィーチャーゲートを有効にしている。
Confidential compute attestation Operator がインストールされている。

手順

次のコマンドを実行してエッジルートを作成します。
```
$ oc create route edge --service=kbs-service --port kbs-port \
  -n trustee-operator-system
```
注記
注記: 現在、有効な CA 署名証明書を持つルートのみがサポートされています。自己署名証明書を使用したルートは使用できません。

次のコマンドを実行して、TRUSTEE_HOST 変数を設定します。

$ TRUSTEE_HOST=$(oc get route -n trustee-operator-system kbs-service \
  -o jsonpath={.spec.host})

次のコマンドを実行してルートを確認します。

$ echo $TRUSTEE_HOST

出力例

kbs-service-trustee-operator-system.apps.memvjias.eastus.aroapp.io

5.3.3. Confidential Containers フィーチャーゲートの有効化

Confidential Containers フィーチャーゲートを有効にする必要があります。

手順

cc-feature-gate.yaml マニフェストファイルを作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: osc-feature-gates
  namespace: openshift-sandboxed-containers-operator
data:
  confidential: "true"

以下のコマンドを実行して config map を作成します。
```
$ oc apply -f cc-feature-gate.yaml
```

5.3.4. ピア Pod の更新 config map

Confidential Containers のピア Pod config map を更新する必要があります。

注記

Secure Boot を true に設定して、デフォルトで有効にします。デフォルト値は false で、セキュリティーリスクが発生します。

手順

以下の例に従って peer-pods-cm.yaml マニフェストファイルを作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: peer-pods-cm
  namespace: openshift-sandboxed-containers-operator
data:
  CLOUD_PROVIDER: "libvirt"
  DISABLECVM: "false"

以下のコマンドを実行して config map を作成します。
```
$ oc apply -f peer-pods-cm.yaml
```
次のコマンドを実行して、peerpodconfig-ctrl-caa-daemon デーモンセットを再起動します。
```
$ oc set env ds/peerpodconfig-ctrl-caa-daemon \
  -n openshift-sandboxed-containers-operator REBOOT="$(date)"
```

5.3.5. KataConfig カスタムリソースの削除

コマンドラインを使用して、KataConfig カスタムリソース (CR) を削除できます。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

次のコマンドを実行して、KataConfig CR を削除します。
```
$ oc delete kataconfig example-kataconfig
```
以下のコマンドを実行して、カスタムリソースが削除されたことを確認します。
```
$ oc get kataconfig example-kataconfig
```
出力例
```
No example-kataconfig instances exist
```

5.3.6. ピア Pod シークレットの更新

Confidential Containers のピア Pod シークレットを更新する必要があります。

シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するための認証情報が保存されます。

デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。

前提条件

REDHAT_OFFLINE_TOKEN。Red Hat API トークンで RHEL イメージをダウンロードするためにこのトークンを生成している。
HKD_CRTIBM Z® でのセキュアな実行を可能にする Host Key Document (HKD) 証明書がある。詳細は、IBM ドキュメントの Obtaining a host key document from Resource Link を参照してください。

手順

次の例に従って peer-pods-secret.yaml マニフェストファイルを作成します。
```
apiVersion: v1
kind: Secret
metadata:
  name: peer-pods-secret
  namespace: openshift-sandboxed-containers-operator
type: Opaque
stringData:
  REDHAT_OFFLINE_TOKEN: "<rh_offline_token>" 1
  HKD_CRT: "<hkd_crt_value>" 2
```
1
Operator ビルドイメージに必要な Red Hat オフライントークンを指定します。
2
Operator が構築したイメージに対して IBM Secure Execution を有効にするには、HKD 証明書の値を指定します。
以下のコマンドを実行してシークレットを作成します。
```
$ oc apply -f peer-pods-secret.yaml
```

5.3.7. KataConfig カスタムリソースの再作成

Confidential Containers の KataConfig カスタムリソース (CR) を再作成する必要があります。

重要

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
BIOS および診断ユーティリティーが有効である。
SSD ではなくハードディスクドライブにデプロイしている。
仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
CPU とネットワークが遅い。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

以下の例に従って example-kataconfig.yaml マニフェストファイルを作成します。
```
apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
  name: example-kataconfig
spec:
  enablePeerPods: true
  logLevel: info
#  kataConfigPoolSelector:
#    matchLabels:
#      <label_key>: '<label_value>' 1
```
1
オプション: 特定のノードに kata-remote をインストールするためにノードラベルを適用した場合は、キーと値を指定します (例: cc: 'true')。
次のコマンドを実行して、KataConfig CR を作成します。
```
$ oc apply -f example-kataconfig.yaml
```
新しい KataConfig CR が作成され、ワーカーノードに kata-remote がランタイムクラスとしてインストールされます。
インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。
次のコマンドを実行して、インストールの進行状況を監視します。
```
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
```
kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata はクラスターにインストールされます。
次のコマンドを実行して、ピア Pod イメージが構築され、libvirt ボリュームにアップロードされたことを確認します。
```
$ oc describe configmap peer-pods-cm -n openshift-sandboxed-containers-operator
```
出力例
```
Name: peer-pods-cm
Namespace: openshift-sandboxed-containers-operator
Labels: <none>
Annotations: <none>

Data
====
CLOUD_PROVIDER: libvirt
DISABLECVM: false 1
LIBVIRT_IMAGE_ID: fa-pp-vol 2

BinaryData
====
Events: <none>
```
1
Operator ビルドイメージの IBM Secure Execution 中に Confidential VM を有効にします。
2
ピア Pod イメージを構築し、libvirt ボリュームにアップロードした場合、値が含まれます。
次のコマンドを実行して、kata-oc マシン設定プールの進行状況を監視し、UPDATEDMACHINECOUNT が MACHINECOUNT と等しいときに UPDATED 状態であることを確認します。
```
$ watch oc get mcp/kata-oc
```

次のコマンドを実行してデーモンセットを確認します。

$ oc get -n openshift-sandboxed-containers-operator ds/peerpodconfig-ctrl-caa-daemon

次のコマンドを実行してランタイムクラスを確認します。

$ oc get runtimeclass

出力例

NAME             HANDLER          AGE
kata             kata             152m
kata-remote      kata-remote      152m

5.3.8. Trustee 認証シークレットの作成

Trustee の認証シークレットを作成する必要があります。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

次のコマンドを実行して、秘密鍵を作成します。
```
$ openssl genpkey -algorithm ed25519 > privateKey
```
次のコマンドを実行して、公開鍵を作成します。
```
$ openssl pkey -in privateKey -pubout -out publicKey
```

次のコマンドを実行してシークレットを作成します。

$ oc create secret generic kbs-auth-public-key --from-file=publicKey -n trustee-operator-system

次のコマンドを実行してシークレットを確認します。
```
$ oc get secret -n trustee-operator-system
```

5.3.9. Trustee config map の作成

Trustee サーバーを設定するには、config map を作成する必要があります。

前提条件

Trustee のルートを作成している。

手順

kbs-config-cm.yaml マニフェストファイルを作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: kbs-config-cm
  namespace: trustee-operator-system
data:
  kbs-config.json: |
    {
      "insecure_http" : true,
      "sockets": ["0.0.0.0:8080"],
      "auth_public_key": "/etc/auth-secret/publicKey",
      "attestation_token_config": {
        "attestation_token_type": "CoCo"
      },
      "repository_config": {
        "type": "LocalFs",
        "dir_path": "/opt/confidential-containers/kbs/repository"
      },
      "as_config": {
        "work_dir": "/opt/confidential-containers/attestation-service",
        "policy_engine": "opa",
        "attestation_token_broker": "Simple",
          "attestation_token_config": {
          "duration_min": 5
          },
        "rvps_config": {
          "store_type": "LocalJson",
          "store_config": {
            "file_path": "/opt/confidential-containers/rvps/reference-values/reference-values.json"
          }
         }
      },
      "policy_engine_config": {
        "policy_path": "/opt/confidential-containers/opa/policy.rego"
      }
    }

以下のコマンドを実行して config map を作成します。
```
$ oc apply -f kbs-config-cm.yaml
```

5.3.10. IBM Secure Execution ヘッダーの取得

IBM Secure Execution (SE) ヘッダーを取得する必要があります。

前提条件

SE ヘッダーを一時的に保存するためのネットワークブロックストレージデバイスがある。

手順

次のコマンドを実行して、SE ヘッダー用の一時フォルダーを作成します。
```
$ mkdir -p /tmp/ibmse/hdr
```
次のコマンドを実行して、IBM s390 Linux リポジトリーから pvextract-hdr ツールをダウンロードします。
```
$ wget https://github.com/ibm-s390-linux/s390-tools/raw/v2.33.1/rust/pvattest/tools/pvextract-hdr -O /tmp/pvextract-hdr
```
次のコマンドを実行して、ツールを実行可能にします。
```
$ chmod +x /tmp/pvextract-hdr
```
次のコマンドを実行して、$IMAGE_OUTPUT_DIR 変数を設定します。
```
$ export IMAGE=$IMAGE_OUTPUT_DIR/se-podvm-commit-short-id.qcow2
```
次のコマンドを実行して、$IMAGE 変数を設定します。
```
$ export IMAGE=/root/rooo/se-podvm-d1fb986-dirty-s390x.qcow2
```
次のコマンドを実行して、nbd カーネルモジュールを有効にします。
```
$ modprobe nbd
```
次のコマンドを実行して、SE イメージをネットワークブロックデバイス (NBD) として接続します。
```
$ qemu-nbd --connect=/dev/nbd0 $IMAGE
```
次のコマンドを実行して、SE イメージのマウントディレクトリーを作成します。
```
$ mkdir -p /mnt/se-image/
```
次のコマンドを実行してプロセスを一時停止します。
```
$ sleep 1
```

次のコマンドを実行して、ブロックデバイスをリスト表示します。

$ lsblk

出力例

nbd0                                           43:0    0  100G  0 disk
├─nbd0p1                                       43:1    0  255M  0 part
├─nbd0p2                                       43:2    0    6G  0 part
│ └─luks-e23e15fa-9c2a-45a5-9275-aae9d8e709c3 253:2    0    6G  0 crypt
└─nbd0p3                                       43:3    0 12.4G  0 part
nbd1                                           43:32   0   20G  0 disk
├─nbd1p1                                       43:33   0  255M  0 part
├─nbd1p2                                       43:34   0    6G  0 part
│ └─luks-5a540f7c-c0cb-419b-95e0-487670d91525 253:3    0    6G  0 crypt
└─nbd1p3                                       43:35   0 86.9G  0 part
nbd2                                           43:64   0    0B  0 disk
nbd3                                           43:96   0    0B  0 disk
nbd4                                           43:128  0    0B  0 disk
nbd5                                           43:160  0    0B  0 disk
nbd6                                           43:192  0    0B  0 disk
nbd7                                           43:224  0    0B  0 disk
nbd8                                           43:256  0    0B  0 disk
nbd9                                           43:288  0    0B  0 disk
nbd10                                          43:320  0    0B  0 disk

使用可能な NBD パーティションに SE イメージディレクトリーをマウントし、次のコマンドを実行して SE ヘッダーを抽出します。
```
$ mount /dev/<nbdXp1> /mnt/se-image/ /tmp/pvextract-hdr \
  -o /tmp/ibmse/hdr/hdr.bin /mnt/se-image/se.img
```
出力例
```
SE header found at offset 0x014000
SE header written to '/tmp/ibmse/hdr/hdr.bin' (640 bytes)
```
NBD が利用できない場合は、次のエラーが表示されます。
```
mount: /mnt/se-image: can't read superblock on /dev/nbd0p1
```
次のコマンドを実行して、SE イメージディレクトリーをアンマウントします。
```
$ umount /mnt/se-image/
```
次のコマンドを実行して、ネットワークブロックストレージデバイスを切断します。
```
$ qemu-nbd --disconnect /dev/nbd0
```

5.3.11. IBM Secure Execution 証明書と鍵の設定

ワーカーノードの IBM Secure Execution (SE) 証明書とキーを設定する必要があります。

前提条件

bastion ノードの IP アドレスがある。
ワーカーノードの内部 IP アドレスがある。

手順

次の手順を実行して、アテステーションポリシーフィールドを取得します。
1. 次のコマンドを実行して、OpenShift Trustee リポジトリーから se_parse_hdr.py スクリプトをダウンロードします。
```
$ wget https://github.com/openshift/trustee/raw/main/attestation-service/verifier/src/se/se_parse_hdr.py -O /tmp/se_parse_hdr.py
```
2. 次のコマンドを実行して、SE Host Key Document (HKD) 証明書用の一時ディレクトリーを作成します。
```
$ mkdir /tmp/ibmse/hkds/
```
3. 次のコマンドを実行して、Host Key Document (HKD) 証明書を一時ディレクトリーにコピーします。
```
$ cp ~/path/to/<hkd_cert.crt> /tmp/ibmse/hkds/<hkd_cert.crt>
```
  注記
  HKD 証明書は、ピア Pod シークレットを作成したときにダウンロードした証明書と同じである必要があります。
4. se_parse_hdr.py スクリプトを実行して、アテステーションポリシーフィールドを取得します。
```
$ python3 /tmp/se_parse_hdr.py /tmp/ibmse/hdr/hdr.bin /tmp/ibmse/hkds/<hkd_cert.crt>
```
  出力例
```
...
  ================================================
  se.image_phkh: xxx
  se.version: 256
  se.tag: xxx
  se.attestation_phkh: xxx
```
  SE アテステーションポリシー config map のこれらの値を記録します。
次の手順を実行して、証明書と証明書失効リスト (CRL) を取得します。
1. 次のコマンドを実行して、証明書用の一時ディレクトリーを作成します。
```
$ mkdir /tmp/ibmse/certs
```
2. 以下のコマンドを実行して、ibm-z-host-key-signing-gen2.crt 証明書をダウンロードします。
```
$ wget https://www.ibm.com/support/resourcelink/api/content/public/ibm-z-host-key-signing-gen2.crt -O /tmp/ibmse/certs/ibm-z-host-key-signing-gen2.crt
```
3. 次のコマンドを実行して、DigiCertCA.crt 証明書をダウンロードします。
```
$ wget https://www.ibm.com/support/resourcelink/api/content/public/DigiCertCA.crt -O /tmp/ibmse/certs/DigiCertCA.crt
```
4. 次のコマンドを実行して、CRL の一時ディレクトリーを作成します。
```
$ mkdir /tmp/ibmse/crls
```
5. 次のコマンドを実行して、DigiCertTrustedRootG4.crl ファイルをダウンロードします。
```
$ wget http://crl3.digicert.com/DigiCertTrustedRootG4.crl -O /tmp/ibmse/crls/DigiCertTrustedRootG4.crl
```
6. 次のコマンドを実行して、DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl ファイルをダウンロードします。
```
$ wget http://crl3.digicert.com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl -O /tmp/ibmse/crls/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
```
RSA 鍵を生成します。
1. 次のコマンドを実行して RSA のキーペアを生成します。
```
$ openssl genrsa -aes256 -passout pass:<password> -out /tmp/encrypt_key-psw.pem 4096 1
```
  1
  RSA 鍵のパスワードを指定します。
2. 次のコマンドを実行して、RSA 鍵の一時ディレクトリーを作成します。
```
$ mkdir /tmp/ibmse/rsa
```
3. 次のコマンドを実行して encrypt_key.pub 鍵を作成します。
```
$ openssl rsa -in /tmp/encrypt_key-psw.pem -passin pass:<password> -pubout -out /tmp/ibmse/rsa/encrypt_key.pub
```
4. 以下のコマンドを実行して encrypt_key.pem 鍵を作成します。
```
$ openssl rsa -in /tmp/encrypt_key-psw.pem -passin pass:<password> -out /tmp/ibmse/rsa/encrypt_key.pem
```

次のコマンドを実行して、/tmp/ibmse ディレクトリーの構造を確認します。

$ tree /tmp/ibmse

出力例

/tmp/ibmse
├── certs
│   ├── ibm-z-host-key-signing-gen2.crt
|   └── DigiCertCA.crt
├── crls
│   └── ibm-z-host-key-gen2.crl
│   └── DigiCertTrustedRootG4.crl
│   └── DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
├── hdr
│   └── hdr.bin
├── hkds
│   └── <hkd_cert.crt>
└── rsa
    ├── encrypt_key.pem
    └── encrypt_key.pub

以下の手順を実行して、これらのファイルを OpenShift Container Platform ワーカーノードにコピーします。
1. 以下のコマンドを実行して、/tmp/ibmse ディレクトリーから圧縮ファイルを作成します。
```
$ tar -czf ibmse.tar.gz -C /tmp/ibmse
```
2. 次のコマンドを実行して、.tar.gz ファイルをクラスターの bastion ノードにコピーします。
```
$ scp /tmp/ibmse.tar.gz root@<ocp_bastion_ip>:/tmp 1
```
  1
  bastion ノードの IP アドレスを指定します。
3. 次のコマンドを実行して、SSH 経由で bastion ノードに接続します。
```
$ ssh root@<ocp_bastion_ip>
```
4. 次のコマンドを実行して、.tar.gz ファイルを各ワーカーノードにコピーします。
```
$ scp /tmp/ibmse.tar.gz core@<worker_node_ip>:/tmp 1
```
  1
  ワーカーノードの IP アドレスを指定します。
5. 次のコマンドを実行して、各ワーカーノードで .tar.gz を抽出します。
```
$ ssh core@<worker_node_ip> 'sudo mkdir -p /opt/confidential-containers/ && sudo tar -xzf /tmp/ibmse.tar.gz -C /opt/confidential-containers/'
```
6. 次のコマンドを実行して、ibmse フォルダーの権限を更新します。
```
$ ssh core@<worker_node_ip> 'sudo chmod -R 755 /opt/confidential-containers/ibmse/'
```

5.3.12. 永続ストレージコンポーネントの作成

ibmse フォルダーを Trustee Pod にマウントするには、永続ストレージコンポーネント、永続ボリューム (PV)、および永続ボリューム要求 (PVC) を作成する必要があります。

手順

persistent-volume.yaml マニフェストファイルを作成します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ibmse-pv
  namespace: trustee-operator-system
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadOnlyMany
  storageClassName: ""
  local:
    path: /opt/confidential-containers/ibmse
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: node-role.kubernetes.io/worker
              operator: Exists

以下のコマンドを実行して永続ボリュームを作成します。
```
$ oc apply -f persistent-volume.yaml
```

persistent-volume-claim.yaml マニフェストファイルを作成します。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ibmse-pvc
  namespace: trustee-operator-system
spec:
  accessModes:
    - ReadOnlyMany
  storageClassName: ""
  resources:
    requests:
      storage: 100Mi

以下のコマンドを実行して永続ボリューム要求を作成します。
```
$ oc apply -f persistent-volume-claim.yaml
```

5.3.13. アテステーションポリシーの設定

次のアテステーションポリシー設定を指定できます。

参照値

ハードウェアプラットフォームの信頼できるダイジェストを指定することにより、Reference Value Provider Service (RVPS) の参照値を設定できます。

クライアントは、実行中のソフトウェア、Trusted Execution Environment (TEE) のハードウェアとファームウェアから測定値を収集し、請求とともに見積りを Attestation Server に送信します。これらの測定値は、Trustee に登録された信頼できるダイジェストと一致する必要があります。このプロセスにより、Confidential VM (CVM) が期待どおりのソフトウェアスタックを実行し、改ざんがされていないように確認します。

クライアントのシークレット

アテストされたクライアントと共有するシークレットを 1 つ以上作成する必要があります。

リソースアクセスポリシー

アクセスするリソースを決定するには、Trustee ポリシーエンジンのポリシーを設定する必要があります。

Trustee ポリシーエンジンと、TEE 証拠の有効性を決定する Attestation Service ポリシーエンジンを混同しないでください。

アテステーションポリシー

IBM Secure Execution のアテステーションポリシーを作成する必要があります。

手順

rvps-configmap.yaml マニフェストファイルを作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: rvps-reference-values
  namespace: trustee-operator-system
data:
  reference-values.json: |
    [ 1
    ]

1: この値は空のままにします。

次のコマンドを実行して、RVPS config map を作成します。
```
$ oc apply -f rvps-configmap.yaml
```
次の例に従って、アテストされたクライアントと共有する 1 つ以上のシークレットを作成します。
```
$ oc create secret generic kbsres1 --from-literal key1=<res1val1> \
  --from-literal key2=<res1val2> -n trustee-operator-system
```
この例では、kbsres1 シークレットには 2 つのエントリー (key1、key2) があり、Trustee クライアントはこれらを取得します。要件に応じてシークレットを追加できます。
resourcepolicy-configmap.yaml マニフェストファイルを作成します。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: resource-policy
  namespace: trustee-operator-system
data:
  policy.rego: | 1
    package policy 2
    path := split(data["resource-path"], "/")
    default allow = false
    allow {
      count(path) == 3
      input["tee"] == "se"
    }
```
1
リソースポリシーの名前 policy.rego は、Trustee config map で定義されたリソースポリシーと一致する必要があります。
2
リソースポリシーは Open Policy Agent 仕様に準拠します。この例では、TEE がサンプルのアテスターでない場合にすべてのリソースを取得できます。
次のコマンドを実行して、リソースポリシーの config map を作成します。
```
$ oc apply -f resourcepolicy-configmap.yaml
```

attestation-policy.yaml マニフェストファイルを作成します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: attestation-policy
  namespace: trustee-operator-system
data:
  default.rego: | 1
    package policy
    import rego.v1
    default allow = false
    converted_version := sprintf("%v", [input["se.version"]])
    allow if {
        input["se.attestation_phkh"] == "<se.attestation_phkh>" 2
        input["se.image_phkh"] == "<se.image_phkh>"
        input["se.tag"] == "<se.tag>"
        converted_version == "256"
    }

1: ポリシー名は変更しないでください。
2: se_parse_hdr.py スクリプトを実行して、取得したアテステーションポリシーフィールドを指定します。

以下のコマンドを実行して、アテステーションポリシー config map を作成します。
```
$ oc apply -f attestation-policy.yaml
```

5.3.14. KbsConfig カスタムリソースの作成

Trustee を起動するには、KbsConfig カスタムリソース (CR) を作成する必要があります。

次に、Trustee Pod および Pod ログをチェックして設定を確認します。

手順

kbsconfig-cr.yaml マニフェストファイルを作成します。

apiVersion: confidentialcontainers.org/v1alpha1
kind: KbsConfig
metadata:
  labels:
    app.kubernetes.io/name: kbsconfig
    app.kubernetes.io/instance: kbsconfig
    app.kubernetes.io/part-of: trustee-operator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: trustee-operator
  name: kbsconfig
  namespace: trustee-operator-system
spec:
  kbsConfigMapName: kbs-config-cm
  kbsAuthSecretName: kbs-auth-public-key
  kbsDeploymentType: AllInOneDeployment
  kbsRvpsRefValuesConfigMapName: rvps-reference-values
  kbsSecretResources: ["kbsres1"]
  kbsResourcePolicyConfigMapName: resource-policy
  kbsAttestationPolicyConfigMapName: attestation-policy
  kbsServiceType: NodePort
  ibmSEConfigSpec:
    certStorePvc: ibmse-pvc

以下のコマンドを実行して KbsConfig CR を作成します。
```
$ oc apply -f kbsconfig-cr.yaml
```

検証

次のコマンドを実行して、デフォルトのプロジェクトを設定します。
```
$ oc project trustee-operator-system
```

次のコマンドを実行して Pod を確認します。

$ oc get pods -n trustee-operator-system

出力例

NAME                                                   READY   STATUS    RESTARTS   AGE
trustee-deployment-8585f98449-9bbgl                    1/1     Running   0          22m
trustee-operator-controller-manager-5fbd44cd97-55dlh   2/2     Running   0          59m

次のコマンドを実行して POD_NAME 環境変数を設定します。

$ POD_NAME=$(oc get pods -l app=kbs -o jsonpath='{.items[0].metadata.name}' -n trustee-operator-system)

次のコマンドを実行して、Pod ログを確認します。

$ oc logs -n trustee-operator-system $POD_NAME

出力例

[2024-05-30T13:44:24Z INFO  kbs] Using config file /etc/kbs-config/kbs-config.json
[2024-05-30T13:44:24Z WARN  attestation_service::rvps] No RVPS address provided and will launch a built-in rvps
[2024-05-30T13:44:24Z INFO  attestation_service::token::simple] No Token Signer key in config file, create an ephemeral key and without CA pubkey cert
[2024-05-30T13:44:24Z INFO  api_server] Starting HTTPS server at [0.0.0.0:8080]
[2024-05-30T13:44:24Z INFO  actix_server::builder] starting 12 workers
[2024-05-30T13:44:24Z INFO  actix_server::server] Tokio runtime found; starting in existing Tokio runtime

次のコマンドを実行して、ibmse-pvc 永続ボリューム要求を Trustee Pod に公開します。

$ oc patch deployment trustee-deployment --namespace=trustee-operator-system --type=json -p='[{"op": "remove", "path": "/spec/template/spec/volumes/5/persistentVolumeClaim/readOnly"}]'

次のコマンドを実行して、kbs-service がノードポートで公開されていることを確認します。
```
$ oc get svc kbs-service -n trustee-operator-system
```
出力例
```
NAME          TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kbs-service   NodePort   198.51.100.54   <none>        8080:31862/TCP   23h
```
kbs-service の URL は `https://<worker_node_ip>:<node_port>` です (例: `https://172.16.0.56:31862`)。

5.3.15. アテステーションプロセスの確認

テスト Pod を作成し、そのシークレットを取得することで、アテステーションプロセスを検証できます。Pod イメージは、Key Broker Service と基本的なアテステーションフローをテストするためのツールである KBS クライアントをデプロイします。

重要

この手順は、アテステーションが機能していることを確認する例です。データはメモリーダンプを使用してキャプチャーされる可能性があるため、機密データを標準 I/O に書き込まないでください。メモリーに書き込まれたデータのみが暗号化されます。

前提条件

Trustee サーバーとテスト Pod が同じクラスター内で実行されていない場合は、ルートが作成されている。

手順

verification-pod.yaml マニフェストファイルを作成します。

apiVersion: v1
kind: Pod
metadata:
  name: kbs-client
spec:
  containers:
  - name: kbs-client
    image: quay.io/confidential-containers/kbs-client:latest
    imagePullPolicy: IfNotPresent
    command:
      - sleep
      - "360000"
    env:
      - name: RUST_LOG
        value:  none

以下のコマンドを実行して Pod を作成します。
```
$ oc create -f verification-pod.yaml
```
次のコマンドを実行して、https.crt ファイルを kbs-client Pod にコピーします。
```
$ oc cp https.crt kbs-client:/
```
次のコマンドを実行して Pod シークレットを取得します。
```
$ oc exec -it kbs-client -- kbs-client --cert-file https.crt \
  --url https://kbs-service:8080 get-resource \
  --path default/kbsres1/key1
```
出力例
```
res1val1
```
Trustee サーバーは、証明書が成功した場合にのみシークレットを返します。

5.3. IBM Z および IBM LinuxONE への Confidential Containers のデプロイ

5.3.1. Confidential compute attestation Operator のインストール

5.3.2. Trustee のルートの作成

5.3.3. Confidential Containers フィーチャーゲートの有効化

5.3.4. ピア Pod の更新 config map

5.3.5. KataConfig カスタムリソースの削除

5.3.6. ピア Pod シークレットの更新

5.3.7. KataConfig カスタムリソースの再作成

5.3.8. Trustee 認証シークレットの作成

5.3.9. Trustee config map の作成

5.3.10. IBM Secure Execution ヘッダーの取得

5.3.11. IBM Secure Execution 証明書と鍵の設定

5.3.12. 永続ストレージコンポーネントの作成

5.3.13. アテステーションポリシーの設定

5.3.14. KbsConfig カスタムリソースの作成

5.3.15. アテステーションプロセスの確認

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links