この記事では、ARO クラスターの Confidential Containers をデプロイするために必要な手順について説明します。 このプロセスには、2 つの主要な部分と複数の手順が含まれます:
最初に、次の手順を含む OpenShift サンドボックス コンテナーをデプロイします:
OpenShift サンドボックス コンテナー オペレーターをインストールします。
ピア ポッド シークレットを作成します。
ピア ポッド構成マップを作成します。
Azure シークレットを作成します。
OpenShift サンドボックス コンテナーをデプロイした後、Confidential Containers をデプロイします。 これを行うには、次の手順を実行します。
トラスティ オペレーターをインストールします。
トラスティのルートを作成します。
Confidential Containers 機能ゲートを有効にします。
ピア ポッド構成マップを更新します。
KataConfig カスタム リソースを作成します。
トラスティ認証シークレットを作成します。
トラスティ構成マップを作成します。
トラスティを構成します。
KbsConfig カスタム リソースを作成します。
構成証明プロセスを確認します。
開始する前に
デプロイ プロセスを開始する前に、次の前提条件が満たされていることを確認します:
少なくとも 1 つのワーカー ノードを持つ既存の ARO クラスター (バージョン 4.15 以降)
cluster-adminロールを持つクラスターへのアクセス
重要
アプリケーション内のポッドごとに、対応する機密仮想マシン (CVM) との 1 対 1 のマッピングがあります。 つまり、すべての新しいポッドには個別の CVM が必要であり、ポッド間の分離が確保されます。
パート 1: OpenShift サンドボックス コンテナーをデプロイする
OpenShift サンドボックス コンテナー オペレーターをインストールする
OpenShift サンドボックス コンテナー オペレーターは、CLI または OpenShift Web コンソールを使用してインストールできます。
osc-namespace.yamlマニフェスト ファイルを作成します:apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator次のコマンドを実行して名前空間を作成します:
$ oc apply -f osc-namespace.yamlosc-operatorgroup.yamlマニフェスト ファイルを作成します:apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator次のコマンドを実行して、演算子グループを作成します:
$ oc apply -f osc-operatorgroup.yamlosc-subscription.yamlマニフェスト ファイルを作成します:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: channel: stable installPlanApproval: Automatic name: sandboxed-containers-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: sandboxed-containers-operator.v1.7.0次のコマンドを実行して、サブスクリプションを作成します:
$ oc apply -f osc-subscription.yaml次のコマンドを実行して、オペレーターが正しくインストールされていることを確認します:
$ oc get csv -n openshift-sandboxed-containers-operator注
このコマンドは、完了までに数分かかる場合があります。
次のコマンドを実行して、プロセスを監視します:
$ watch oc get csv -n openshift-sandboxed-containers-operator出力例
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.7.0 1.6.0 Succeeded
Web コンソールで、オペレーター → OperatorHub に移動します。
[キーワードでフィルター処理する] フィールドに、「OpenShift サンドボックス コンテナー」と入力します。
[OpenShift サンドボックス コンテナー オペレーター ] タイルを選択し、[インストール] を選択します。
[インストール オペレーター] ページで、使用可能な 更新チャネル オプションの一覧から [安定] を選択します。
インストール済みの名前空間に対して、オペレーターが推奨する名前空間が選択されていることを確認します。 これにより、必須の
openshift-sandboxed-containers-operator名前空間にオペレーターがインストールされます。 この名前空間がまだ存在しない場合は、自動的に作成されます。注
openshift-sandboxed-containers-operator 以外の名前空間に OpenShift サンドボックス コンテナー オペレーターをインストールしようとすると、インストールが失敗します。
承認戦略では自動が選択されていることを確認します。 自動 が既定値であり、新しい z ストリーム リリースが利用可能になったときに OpenShift サンドボックス コンテナーの自動更新を有効にします。
[インストール] を選択します。
オペレーター →インストール済みオペレーター に移動して、オペレーターがインストールされていることを確認します。
ピア ポッド シークレットを作成する
OpenShift サンドボックス コンテナーのピア ポッド シークレットを作成する必要があります。 シークレットには、ポッド仮想マシン (VM) イメージとピア ポッド インスタンスを作成するための資格情報が格納されます。
既定では、OpenShift サンドボックス コンテナー オペレーターは、クラスターの作成に使用される資格情報に基づいてシークレットを作成します。 ただし、別の資格情報を使用するシークレットを手動で作成できます。
次のコマンドを実行して、Azure サブスクリプション ID を取得します:
$ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" \ -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""次のコマンドを実行して、ロールベースのアクセス制御 (RBAC) コンテンツを生成します:
$ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID \ --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"出力例
{ "client_id": `AZURE_CLIENT_ID`, "client_secret": `AZURE_CLIENT_SECRET`, "tenant_id": `AZURE_TENANT_ID` }シークレット オブジェクトで使用する RBAC 出力を記録します。
次の例に従って peer-pods-secret.yaml マニフェスト ファイルを作成します:
apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AZURE_CLIENT_ID: "<azure_client_id>" AZURE_CLIENT_SECRET: "<azure_client_secret>" AZURE_TENANT_ID: "<azure_tenant_id>" AZURE_SUBSCRIPTION_ID: "<azure_subscription_id>"-
AZURE_CLIENT_ID valueを指定します。 -
AZURE_CLIENT_SECRET valueを指定します。 -
AZURE_TENANT_ID valueを指定します。 -
AZURE_SUBSCRIPTION_ID valueを指定します。
-
次のコマンドを実行してシークレットを作成します:
$ oc apply -f peer-pods-secret.yaml
ピア ポッド構成マップを作成する
Azure から次の値を取得します:
Azure リソース グループを取得して記録します:
$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""Azure VNet 名を取得して記録します:
$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)この値は、Azure サブネット ID を取得するために使用されます。
Azure サブネット ID を取得して記録します:
$ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""Azure ネットワーク セキュリティ グループ (NSG) ID を取得して記録します:
$ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""Azure リージョンを取得して記録します:
$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
次の例に従って peer-pods-cm.yaml マニフェスト ファイルを作成します:
apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_B2als_v2" AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5" AZURE_SUBNET_ID: "<azure_subnet_id>" AZURE_NSG_ID: "<azure_nsg_id>" PROXY_TIMEOUT: "5m" AZURE_IMAGE_ID: "<azure_image_id>" AZURE_REGION: "<azure_region>" AZURE_RESOURCE_GROUP: "<azure_resource_group>" DISABLECVM: "true"- ワークロードでインスタンス サイズが定義されていない場合は、
AZURE_INSTANCE_SIZEが既定値です。 -
AZURE_INSTANCE_SIZESは、ポッドの作成時に指定できるすべてのインスタンス サイズが一覧表示されます。 これにより、必要なメモリが少なく、CPU の数が少なく、大規模なワークロードではインスタンス サイズが大きいワークロードに対して、より小さなインスタンス サイズを定義できます。 - 取得した
AZURE_SUBNET_ID値を指定します。 - 取得した
AZURE_NSG_ID値を指定します。 -
AZURE_IMAGE_IDはオプションです。 既定では、この値は、クラスターの資格情報に基づく Azure イメージ ID を使用して KataConfig カスタム リソースを実行するときに設定されます。 独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。 - 取得した
AZURE_REGION値を指定します。 - 取得した
AZURE_RESOURCE_GROUP値を指定します。
- ワークロードでインスタンス サイズが定義されていない場合は、
次のコマンドを実行して、構成マップを作成します:
$ oc apply -f peer-pods-cm.yaml
Azure シークレットを作成する
Azure が仮想マシンの作成に使用する SSH キー シークレットを作成する必要があります。
次のコマンドを実行して、SSH キー ペアを生成します:
$ ssh-keygen -f ./id_rsa -N ""次のコマンドを実行して、シークレット オブジェクトを作成します:
$ oc create secret generic ssh-key-secret \ -n openshift-sandboxed-containers-operator \ --from-file=id_rsa.pub=./id_rsa.pub作成した SSH キーを削除します:
$ shred --remove id_rsa.pub id_rsa
パート 2: 機密コンテナーをデプロイする
トラスティ オペレーターをインストールする
trustee-namespace.yaml マニフェスト ファイルを作成します:
apiVersion: v1 kind: Namespace metadata: name: trustee-operator-system次のコマンドを実行して、トラスティ演算子システム名前空間を作成します:
$ oc apply -f trustee-namespace.yamlrustee-operatorgroup.yaml マニフェスト ファイルを作成します:
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: trustee-operator-group namespace: trustee-operator-system spec: targetNamespaces: - trustee-operator-system次のコマンドを実行して、オペレーター グループを作成します:
$ oc apply -f trustee-operatorgroup.yamltrustee-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次のコマンドを実行して、オペレーターが正しくインストールされていることを確認します:
$ 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
トラスティのルートを作成する
トラスティのエッジ TLS 終端を使用して、セキュリティで保護されたルートを作成します。 外部イングレス トラフィックは、HTTPS としてルーター ポッドに到達し、HTTP としてトラスティ ポッドに渡されます。
次のコマンドを実行してエッジ ルートを作成します:
$ 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ピア ポッド構成マップのこの値を記録します。
Confidential Containers 機能ゲートを有効にする
cc-feature-gate.yamlマニフェスト ファイルを作成します:apiVersion: v1 kind: ConfigMap metadata: name: osc-feature-gates namespace: openshift-sandboxed-containers-operator data: confidential: "true"次のコマンドを実行して、構成マップを作成します:
$ oc apply -f cc-feature-gate.yaml
ピア ポッド構成マップを更新する
Azure インスタンスから次の値を取得します:
一. Azure リソース グループを取得して記録します:
$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""二. Azure VNet 名を取得して記録します:
$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)この値は、Azure サブネット ID を取得するために使用されます。
iii. Azure サブネット ID を取得して記録します:
$ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""iv. Azure ネットワーク セキュリティ グループ (NSG) ID を取得して記録します:
$ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""v. Azure リージョンを取得して記録します:
$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""次の例に従って、
peer-pods-cm.yamlマニフェスト ファイルを作成します:apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_DC2as_v5" AZURE_INSTANCE_SIZES: "Standard_DC2as_v5,Standard_DC4as_v5,Standard_DC8as_v5" AZURE_SUBNET_ID: "<azure_subnet_id>" AZURE_NSG_ID: "<azure_nsg_id>" PROXY_TIMEOUT: "5m" AZURE_IMAGE_ID: "<azure_image_id>" AZURE_REGION: "<azure_region>" AZURE_RESOURCE_GROUP: "<azure_resource_group>" DISABLECVM: "false" AA_KBC_PARAMS: "cc_kbc::https://${TRUSTEE_HOST}"- ワークロードでインスタンス サイズが定義されていない場合は、
AZURE_INSTANCE_SIZEが既定値です。 TDX の場合は、"Standard_EC4eds_v5" を指定します。 -
AZURE_INSTANCE_SIZESは、ポッドの作成時に指定できるすべてのインスタンス サイズが一覧表示されます。 これにより、必要なメモリが少なく、CPU の数が少なく、大規模なワークロードではインスタンス サイズが大きいワークロードに対して、より小さなインスタンス サイズを定義できます。 TDX の場合は、"Standard_EC4eds_v5、Standard_EC8eds_v5、Standard_EC16eds_v5" を指定します。 - 取得した
AZURE_SUBNET_ID値を指定します。 - 取得した
AZURE_NSG_ID値を指定します。 -
AZURE_IMAGE_ID(オプション) 既定では、この値は、クラスターの資格情報に基づく Azure イメージ ID を使用して KataConfig カスタム リソースを実行するときに設定されます。 独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。 - 取得した
AZURE_REGION値を指定します。 - 取得した
AZURE_RESOURCE_GROUP値を指定します。 -
AA_KBC_PARAMSトラスティ ルートのホスト名を指定します。
- ワークロードでインスタンス サイズが定義されていない場合は、
次のコマンドを実行して、構成マップを作成します:
$ 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)"
KataConfig カスタム リソースを作成する
次の例に従って、
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>'オプション: 特定のノードに kata-remote をインストールするためにノード ラベルを適用した場合は、キーと値 (例: cc: 'true') を指定します。
次のコマンドを実行して、KataConfig カスタム リソースを作成します:
$ oc apply -f example-kataconfig.yaml新しい KataConfig カスタム リソースが作成され、ワーカー ノードにランタイム クラスとして kata-remote がインストールされます。
注
インストールを確認する前に、kata-remote インストールが完了し、ワーカー ノードが再起動するまで待ちます。
次のコマンドを実行して、インストールの進行状況を監視します:
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"kataNodes のすべてのワーカーの状態がインストールされ、理由を指定せずに InProgress の条件が False の場合、kata-remote がクラスターにインストールされます。
次のコマンドを実行して、デーモン セットを確認します:
$ oc get -n openshift-sandboxed-containers-operator ds/peerpodconfig-ctrl-caa-daemon次のコマンドを実行して、ランタイム クラスを確認します:
$ oc get runtimeclass
出力例
NAME HANDLER AGE kata-remote kata-remote 152m
トラスティ認証シークレットを作成する
次のコマンドを実行して秘密キーを作成します:
$ 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
トラスティ構成マップを作成する
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" } }次のコマンドを実行して、構成マップを作成します:
$ oc apply -f kbs-config-cm.yaml
トラスティを構成する
次のトラスティ設定を構成します。
参照値を構成する
ハードウェア プラットフォームの信頼できるダイジェストを指定することで、参照値プロバイダー サービス (RVPS) の参照値を構成できます。
クライアントは、実行中のソフトウェア、トラステッド実行環境 (TEE) ハードウェア、ファームウェアから測定値を収集し、要求を含む見積もりを構成証明サーバーに送信します。 これらの測定値は、トラスティに登録されている信頼できるダイジェストと一致する必要があります。 このプロセスにより、機密 VM (CVM) が想定されるソフトウェア スタックを実行しており、改ざんされていないことが保証されます。
rvps-configmap.yamlマニフェスト ファイルを作成します:apiVersion: v1 kind: ConfigMap metadata: name: rvps-reference-values namespace: trustee-operator-system data: reference-values.json: | [ ]必要に応じて、
reference-values.jsonハードウェア プラットフォームの信頼できるダイジェストを指定します。 それ以外の場合は、空のままにします。次のコマンドを実行して、RVPS 構成マップを作成します:
$ oc apply -f rvps-configmap.yaml
独自の構成証明ポリシーを作成する
独自の構成証明ポリシーを作成することで、既定の構成証明ポリシーを上書きできます。
次の例に従って、attestation-policy.yaml マニフェスト ファイルを作成します:
apiVersion: v1 kind: ConfigMap metadata: name: attestation-policy namespace: trustee-operator-system data: default.rego: | package policy import future.keywords.every default allow = false allow { every k, v in input { judge_field(k, v) } } judge_field(input_key, input_value) { has_key(data.reference, input_key) reference_value := data.reference[input_key] match_value(reference_value, input_value) } judge_field(input_key, input_value) { not has_key(data.reference, input_key) } match_value(reference_value, input_value) { not is_array(reference_value) input_value == reference_value } match_value(reference_value, input_value) { is_array(reference_value) array_include(reference_value, input_value) } array_include(reference_value_array, input_value) { reference_value_array == [] } array_include(reference_value_array, input_value) { reference_value_array != [] some i reference_value_array[i] == input_value } has_key(m, k) { _ = m[k] }package policyの場合、構成証明ポリシーは Open Policy Agent の仕様に従います。 この例では、構成証明ポリシーは、構成証明レポートで指定された要求を、RVPS データベースに登録されている参照値と比較します。 構成証明プロセスは、すべての値が一致する場合にのみ成功します。次のコマンドを実行して、構成証明ポリシー構成マップを作成します:
$ oc apply -f attestation-policy.yaml
TDX の証明書キャッシュ サービスのプロビジョニング
TEE が Intel Trust Domain Extensions (TDX) の場合は、プロビジョニング証明書キャッシュ サービス (PCCS) を構成する必要があります。 PCCS はプロビジョニング認定キー (PCK) 証明書を取得し、ローカル データベースにキャッシュします。
tdx-config.yaml マニフェスト ファイルを作成します。
apiVersion: v1 kind: ConfigMap metadata: name: tdx-config namespace: trustee-operator-system data: sgx_default_qcnl.conf: | \ { "collateral_service": "https://api.trustedservices.intel.com/sgx/certification/v4/", "pccs_url": "<pccs_url>" }pccs_urlの場合は、PCCS URL を指定します (例: https://localhost:8081/sgx/certification/v4/.)次のコマンドを実行して、TDX 構成マップを作成します:
$ oc apply -f tdx-config.yaml
コンテナー イメージの署名検証用のシークレットを作成する
コンテナー イメージの署名検証を使用する場合は、コンテナー イメージの公開署名キーを含むシークレットを作成する必要があります。 トラスティ オペレーターはこのシークレットを使用して署名を検証し、信頼された認証済みのコンテナー イメージのみが環境にデプロイされるようにします。
次のコマンドを実行して、コンテナー イメージの署名検証用のシークレットを作成します。
$ oc apply secret generic <type> \ --from-file=<tag>=./<public_key_file> \ -n trustee-operator-system- KBS シークレットの種類 (例:
img-sig) を指定します。 - シークレットのタグ (例:
pub-key) と、コンテナー イメージの公開署名キーを指定します。
- KBS シークレットの種類 (例:
<type>値を記録します。 KbsConfig カスタム リソースを作成する場合は、spec.kbsSecretResources キーにこの値を追加する必要があります。
コンテナー イメージの署名検証ポリシーを作成する
署名の検証は常に有効になっているため、コンテナー イメージの署名検証ポリシーを作成する必要があります。
重要
このポリシーが見つからない場合、ポッドは起動しません。 コンテナー イメージの署名検証を使用しない場合は、署名の検証なしでポリシーを作成します。
次の例に従って security-policy-config.json ファイルを作成します。
署名の検証を使用しない場合:
{ "default": [ { "type": "insecureAcceptAnything" }], "transports": {} }署名の検証を使用する場合:
{ "default": [ { "type": "insecureAcceptAnything" ], "transports": { "<transport>": { "<registry>/<image>": [ { "type": "sigstoreSigned", "keyPath": "kbs:///default/<type>/<tag>" } ] } } }- トランスポート用のイメージ リポジトリ (例: "docker") を指定します。
- コンテナー レジストリとイメージ (例: "quay.io/my-image") を指定します。
- 作成したコンテナー イメージ署名検証シークレットの種類とタグ (例: "img-sig/pub-key") を指定します。
次のコマンドを実行して、セキュリティ ポリシーを作成します。
$ oc apply secret generic security-policy \ --from-file=osc=./<security-policy-config.json> \ -n trustee-operator-systemシークレットの種類、セキュリティ ポリシー、キーなどを変更しないでください。
セキュリティ ポリシーのシークレットは、KbsConfig カスタム リソースの
spec.kbsSecretResourcesキーで指定されます。
KbsConfig カスタム リソースを作成する
トラスティを起動するには、KbsConfig カスタム リソースを作成する必要があります。
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", "security-policy", "<type>"] kbsResourcePolicyConfigMapName: resource-policy # tdxConfigSpec: # kbsTdxConfigMapName: tdx-config # kbsAttestationPolicyConfigMapName: attestation-policy # kbsServiceType: <service_type>- 省略可能: シークレットを作成した場合、コンテナー イメージ署名検証シークレットの
type値 (例:img-sig) を指定します。 シークレットを作成しなかった場合は、kbsSecretResources値を["kbsres1", "security-policy"]に設定します。 - Intel Trust Domain Extensions の場合、
tdxConfigSpec.kbsTdxConfigMapName: tdx-configのコメントを解除します。 - カスタマイズされた構成証明ポリシーを作成する場合は、
kbsAttestationPolicyConfigMapName: attestation-policyのコメントを解除します。 - 既定の ClusterIP サービス以外のサービスの種類を作成して、クラスターの外部トラフィック内のアプリケーションを公開する場合は、
kbsServiceType: <service_type>のコメントを解除します。NodePort、LoadBalancer、またはExternalNameを指定できます。
- 省略可能: シークレットを作成した場合、コンテナー イメージ署名検証シークレットの
次のコマンドを実行して、KbsConfig カスタム リソースを作成します:
$ oc apply -f kbsconfig-cr.yaml
トラスティ構成を確認する
トラスティ ポッドとログを調べて、トラスティ構成を確認します。
次のコマンドを実行して、既定のプロジェクトを設定します:
$ oc project trustee-operator-system次のコマンドを実行して、ポッドを確認します:
$ 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)次のコマンドを実行して、ポッド ログを確認します:
$ 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
構成証明プロセスを確認する
テスト ポッドを作成し、そのシークレットを取得することで、構成証明プロセスを確認できます。
重要: この手順は、構成証明が機能していることを確認する例です。 メモリ ダンプを使用してデータをキャプチャできるため、機密データを標準 I/O に書き込まないでください。 メモリに書き込まれるデータのみが暗号化されます。
既定では、ポッド VM イメージに埋め込まれたエージェント側ポリシーによって、Confidential Containers ポッドの exec API とログ API が無効になります。 このポリシーにより、機密データが標準 I/O に書き込まれないようにします。
テスト シナリオでは、ポッドにポリシー注釈を追加することで、実行時に制限をオーバーライドできます。 Technology Preview の場合、ランタイム ポリシーの注釈はリモート構成証明では検証されません。
verification-pod.yaml マニフェスト ファイルを作成します:
apiVersion: v1 kind: Pod metadata: name: ocp-cc-pod labels: app: ocp-cc-pod annotations: io.katacontainers.config.agent.policy: cGFja2FnZSBhZ2VudF9wb2xpY3kKCmRlZmF1bHQgQWRkQVJQTmVpZ2hib3JzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgQWRkU3dhcFJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENsb3NlU3RkaW5SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBDb3B5RmlsZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENyZWF0ZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENyZWF0ZVNhbmRib3hSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBEZXN0cm95U2FuZGJveFJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IEV4ZWNQcm9jZXNzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgR2V0TWV0cmljc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IEdldE9PTUV2ZW50UmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgR3Vlc3REZXRhaWxzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgTGlzdEludGVyZmFjZXNSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBMaXN0Um91dGVzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgTWVtSG90cGx1Z0J5UHJvYmVSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBPbmxpbmVDUFVNZW1SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBQYXVzZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFB1bGxJbWFnZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFJlYWRTdHJlYW1SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZW1vdmVDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZW1vdmVTdGFsZVZpcnRpb2ZzU2hhcmVNb3VudHNSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZXNlZWRSYW5kb21EZXZSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZXN1bWVDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBTZXRHdWVzdERhdGVUaW1lUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU2V0UG9saWN5UmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU2lnbmFsUHJvY2Vzc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFN0YXJ0Q29udGFpbmVyUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU3RhcnRUcmFjaW5nUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU3RhdHNDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBTdG9wVHJhY2luZ1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFR0eVdpblJlc2l6ZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUVwaGVtZXJhbE1vdW50c1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUludGVyZmFjZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZVJvdXRlc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFdhaXRQcm9jZXNzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgV3JpdGVTdHJlYW1SZXF1ZXN0IDo9IHRydWUK spec: runtimeClassName: kata-remote containers: - name: skr-openshift image: registry.access.redhat.com/ubi9/ubi:9.3 command: - sleep - "36000" securityContext: privileged: false seccompProfile: type: RuntimeDefaultポッド metada
annotationsは、機密データが標準 I/O に書き込まれないようにするポリシーをオーバーライドします。次のコマンドを実行してポッドを作成します:
$ oc create -f verification-pod.yaml次のコマンドを実行して、ocp-cc-pod ポッドの Bash シェルに接続します:
$ oc exec -it ocp-cc-pod -- bash次のコマンドを実行して、ポッド シークレットをフェッチします:
$ curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1出力例
res1val1トラスティ サーバーは、構成証明が成功した場合にのみシークレットを返します。