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) が期待どおりのソフトウェアスタックを実行し、改ざんがされていないように確認します。

手順

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

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: rvps-reference-values
      namespace: trustee-operator-system
    data:
      reference-values.json: |
        [ 
    1
    
        ]
    Copy to Clipboard Toggle word wrap
    1
    必要に応じて、お使いのハードウェアプラットフォームの信頼できるダイジェストを指定します。それ以外の場合は、空のままにします。
  2. 次のコマンドを実行して、RVPS config map を作成します。

    $ oc apply -f rvps-configmap.yaml
    Copy to Clipboard Toggle word wrap

5.9.2. アテステーションポリシーの作成

デフォルトの設定アテステーションポリシーをオーバーライドする設定アテステーションポリシーを作成できます。

手順

  1. 次の例に従って、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]
        }
    Copy to Clipboard Toggle word wrap
    1
    アテステーションポリシーは、Open Policy Agent 仕様に準拠します。この例では、アテステーションポリシーは、アテステーションレポートで提供されたクレームを RVPS データベースに登録されている参照値と比較します。すべての値が一致する場合にのみ、アテステーションプロセスは成功します。
  2. 以下のコマンドを実行して、アテステーションポリシー config map を作成します。

    $ oc apply -f attestation-policy.yaml
    Copy to Clipboard Toggle word wrap

5.9.3. TDX 用の PCCS 設定

Intel Trust Domain Extensions (TDX) を使用する場合は、Provisioning Certificate Caching Service (PCCS) を使用するように Trustee を設定する必要があります。

PCCS はプロビジョニング証明書キー (PCK) 証明書を取得し、ローカルデータベースにキャッシュします。

重要

パブリック Intel PCCS サービスを使用しないでください。オンプレミスまたはパブリッククラウド上のローカルキャッシュサービスを使用します。

手順

  1. 次の例に従って、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
    
          }
    Copy to Clipboard Toggle word wrap
    1
    PCCS URL を指定します (例: https://localhost:8081/sgx/certification/v4/)。
  2. 以下のコマンドを実行して TDX config map を作成します。

    $ oc apply -f tdx-config.yaml
    Copy to Clipboard Toggle word wrap

5.9.4. クライアント用のカスタムキーを使用したシークレットの作成

Trustee クライアント用の 1 つ以上のカスタムキーを含むシークレットを作成できます。

この例では、kbsres1 シークレットには 2 つのエントリー (key1key2) があり、クライアントはそれらを取得します。同じ形式を使用して、要件に応じて追加のシークレットを追加できます。

前提条件

  • 1 つ以上のカスタムキーが作成されている。

手順

  • 次の例に従って、カスタムキーのシークレットを作成します。

    $ oc apply secret generic kbsres1 \
      --from-literal key1=<custom_key1> \ 
    1
    
      --from-literal key2=<custom_key2> \
      -n trustee-operator-system
    Copy to Clipboard Toggle word wrap
    1
    カスタムキーを指定します。

    kbsres1 シークレットは、KbsConfig カスタムリソースの spec.kbsSecretResources キーで指定されます。

5.9.5. コンテナーイメージの署名検証用のシークレット作成

コンテナーイメージの署名検証を使用する場合は、公開コンテナーイメージ署名鍵を含むシークレットを作成する必要があります。

Confidential compute attestation Operator はシークレットを使用して署名を検証し、信頼され、認証されたコンテナーイメージのみが環境にデプロイされるようにします。

Red Hat Trusted Artifact Signer またはその他のツールを使用して、コンテナーイメージに署名できます。

手順

  1. 次のコマンドを実行して、コンテナーイメージの署名検証用のシークレットを作成します。

    $ oc apply secret generic <type> \ 
    1
    
      --from-file=<tag>=./<public_key_file> \ 
    2
    
      -n trustee-operator-system
    Copy to Clipboard Toggle word wrap
    1
    KBS シークレットタイプ (例: img-sig) を指定します。
    2
    シークレットタグ (例: pub-key) とパブリックコンテナーイメージ署名鍵を指定します。
  2. <type> の値を記録します。KbsConfig カスタムリソースを作成するときに、この値を spec.kbsSecretResources キーに追加する必要があります。

5.9.6. コンテナーイメージ署名検証ポリシーの作成

署名検証は常に有効になっているため、コンテナーイメージ署名検証ポリシーを作成します。このポリシーがない場合、Pod は起動しません。

コンテナーイメージの署名検証を使用していない場合は、署名検証なしでポリシーを作成します。

詳細は、containers-policy.json 5 を参照してください。

手順

  1. 次の例に従って、security-policy-config.json ファイルを作成します。

    • 署名検証なし:

      {
        "default": [
        {
          "type": "insecureAcceptAnything"
        }],
        "transports": {}
      }
      Copy to Clipboard Toggle word wrap
    • 署名検証あり:

      {
        "default": [
            {
            "type": "insecureAcceptAnything"
            }
        ],
        "transports": {
            "<transport>": { 
      1
      
                "<registry>/<image>": 
      2
      
                [
                    {
                        "type": "sigstoreSigned",
                        "keyPath": "kbs:///default/<type>/<tag>" 
      3
      
                    }
                ]
            }
        }
      }
      Copy to Clipboard Toggle word wrap
      1
      transport のイメージリポジトリーを指定します (例: "docker")。詳細は、containers-transports 5 を参照してください。
      2
      コンテナーレジストリーとイメージを指定します (例: "quay.io/my-image")。
      3
      作成したコンテナーイメージ署名検証シークレットのタイプとタグを指定します (例: img-sig/pub-key)。
  2. 次のコマンドを実行してセキュリティーポリシーを作成します。

    $ oc apply secret generic security-policy \
      --from-file=osc=./<security-policy-config.json> \
      -n trustee-operator-system
    Copy to Clipboard Toggle word wrap

    シークレットタイプ security-policy または osc のキーを変更しないでください。

    security-policy シークレットは、KbsConfig カスタムリソースの spec.kbsSecretResources キーで指定されます。

5.9.7. リソースアクセスポリシーの作成

Trustee ポリシーエンジンのリソースアクセスポリシーを設定します。このポリシーは、Trustee がアクセスできるリソースを決定します。

注記

Trustee ポリシーエンジンは、TEE 証拠の有効性を決定するアテステーション Service ポリシーエンジンとは異なります。

手順

  1. 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"
        }
    Copy to Clipboard Toggle word wrap
    1
    リソースポリシーの名前 policy.rego は、Trustee config map で定義されたリソースポリシーと一致する必要があります。
    2
    リソースポリシーは Open Policy Agent 仕様に準拠します。この例では、TEE がサンプルのアテスターでない場合にすべてのリソースを取得できます。
  2. 次のコマンドを実行して、リソースポリシーの config map を作成します。

    $ oc apply -f resourcepolicy-configmap.yaml
    Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat