5.9. Trustee の値、ポリシー、およびシークレットの設定
Trustee には次の値、ポリシー、およびシークレットを設定できます。
- オプション: 参照値プロバイダーサービスの参照値。
- オプション: アテステーションポリシー
- Intel Trust Domain Extensions (TDX) 用の証明書キャッシュサービスをプロビジョニングします。
- オプション: Trustee クライアントのカスタムキーのシークレット。
- オプション: コンテナーイメージの署名検証用のシークレット。
- コンテナーイメージの署名検証ポリシー。このポリシーは必須です。コンテナーイメージの署名検証を使用しない場合は、署名を検証しないポリシーを作成する必要があります。
- リソースアクセスポリシー
5.9.1. 参照値の設定
ハードウェアプラットフォームの信頼できるダイジェストを指定することにより、Reference Value Provider Service (RVPS) の参照値を設定できます。
クライアントは、実行中のソフトウェア、Trusted Execution Environment (TEE) のハードウェアとファームウェアから測定値を収集し、請求とともに見積りを Attestation Server に送信します。これらの測定値は、Trustee に登録された信頼できるダイジェストと一致する必要があります。このプロセスにより、Confidential VM (CVM) が期待どおりのソフトウェアスタックを実行し、改ざんがされていないように確認します。
手順
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
5.9.2. アテステーションポリシーの作成
デフォルトの設定アテステーションポリシーをオーバーライドする設定アテステーションポリシーを作成できます。
手順
次の例に従って、
attestation-policy.yaml
マニフェストファイルを作成します。apiVersion: v1 kind: ConfigMap metadata: name: attestation-policy namespace: trustee-operator-system data: default.rego: | package policy 1 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] }
- 1
- アテステーションポリシーは、Open Policy Agent 仕様に準拠します。この例では、アテステーションポリシーは、アテステーションレポートで提供されたクレームを RVPS データベースに登録されている参照値と比較します。すべての値が一致する場合にのみ、アテステーションプロセスは成功します。
以下のコマンドを実行して、アテステーションポリシー config map を作成します。
$ oc apply -f attestation-policy.yaml
5.9.3. TDX 用の PCCS 設定
Intel Trust Domain Extensions (TDX) を使用する場合は、Provisioning Certificate Caching Service (PCCS) を使用するように Trustee を設定する必要があります。
PCCS はプロビジョニング証明書キー (PCK) 証明書を取得し、ローカルデータベースにキャッシュします。
パブリック Intel PCCS サービスを使用しないでください。オンプレミスまたはパブリッククラウド上のローカルキャッシュサービスを使用します。
手順
次の例に従って、
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>" 1 }
- 1
- PCCS URL を指定します (例:
https://localhost:8081/sgx/certification/v4/
)。
以下のコマンドを実行して TDX config map を作成します。
$ oc apply -f tdx-config.yaml
5.9.4. クライアント用のカスタムキーを使用したシークレットの作成
Trustee クライアント用の 1 つ以上のカスタムキーを含むシークレットを作成できます。
この例では、kbsres1
シークレットには 2 つのエントリー (key1
、key2
) があり、クライアントはそれらを取得します。同じ形式を使用して、要件に応じて追加のシークレットを追加できます。
前提条件
- 1 つ以上のカスタムキーが作成されている。
手順
次の例に従って、カスタムキーのシークレットを作成します。
$ oc apply secret generic kbsres1 \ --from-literal key1=<custom_key1> \ 1 --from-literal key2=<custom_key2> \ -n trustee-operator-system
- 1
- カスタムキーを指定します。
kbsres1
シークレットは、KbsConfig
カスタムリソースのspec.kbsSecretResources
キーで指定されます。
5.9.5. コンテナーイメージの署名検証用のシークレット作成
コンテナーイメージの署名検証を使用する場合は、公開コンテナーイメージ署名鍵を含むシークレットを作成する必要があります。
Confidential compute attestation Operator はシークレットを使用して署名を検証し、信頼され、認証されたコンテナーイメージのみが環境にデプロイされるようにします。
Red Hat Trusted Artifact Signer またはその他のツールを使用して、コンテナーイメージに署名できます。
手順
次のコマンドを実行して、コンテナーイメージの署名検証用のシークレットを作成します。
$ oc apply secret generic <type> \ 1 --from-file=<tag>=./<public_key_file> \ 2 -n trustee-operator-system
-
<type>
の値を記録します。KbsConfig
カスタムリソースを作成するときに、この値をspec.kbsSecretResources
キーに追加する必要があります。
5.9.6. コンテナーイメージ署名検証ポリシーの作成
署名検証は常に有効になっているため、コンテナーイメージ署名検証ポリシーを作成します。このポリシーがない場合、Pod は起動しません。
コンテナーイメージの署名検証を使用していない場合は、署名検証なしでポリシーを作成します。
詳細は、containers-policy.json 5 を参照してください。
手順
次の例に従って、
security-policy-config.json
ファイルを作成します。署名検証なし:
{ "default": [ { "type": "insecureAcceptAnything" }], "transports": {} }
署名検証あり:
{ "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "<transport>": { 1 "<registry>/<image>": 2 [ { "type": "sigstoreSigned", "keyPath": "kbs:///default/<type>/<tag>" 3 } ] } } }
次のコマンドを実行してセキュリティーポリシーを作成します。
$ oc apply secret generic security-policy \ --from-file=osc=./<security-policy-config.json> \ -n trustee-operator-system
シークレットタイプ
security-policy
またはosc
のキーを変更しないでください。security-policy
シークレットは、KbsConfig
カスタムリソースのspec.kbsSecretResources
キーで指定されます。
5.9.7. リソースアクセスポリシーの作成
Trustee ポリシーエンジンのリソースアクセスポリシーを設定します。このポリシーは、Trustee がアクセスできるリソースを決定します。
Trustee ポリシーエンジンは、TEE 証拠の有効性を決定するアテステーション Service ポリシーエンジンとは異なります。
手順
resourcepolicy-configmap.yaml
マニフェストファイルを作成します。apiVersion: v1 kind: ConfigMap metadata: name: resource-policy namespace: trustee-operator-system data: policy.rego: | 1 package policy 2 default allow = false allow { input["tee"] != "sample" }
- 1
- リソースポリシーの名前
policy.rego
は、Trustee config map で定義されたリソースポリシーと一致する必要があります。 - 2
- リソースポリシーは Open Policy Agent 仕様に準拠します。この例では、TEE がサンプルのアテスターでない場合にすべてのリソースを取得できます。
次のコマンドを実行して、リソースポリシーの config map を作成します。
$ oc apply -f resourcepolicy-configmap.yaml