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
        ]
    1
    必要に応じて、お使いのハードウェアプラットフォームの信頼できるダイジェストを指定します。それ以外の場合は、空のままにします。
  2. 次のコマンドを実行して、RVPS config map を作成します。

    $ oc apply -f rvps-configmap.yaml

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]
        }
    1
    アテステーションポリシーは、Open Policy Agent 仕様に準拠します。この例では、アテステーションポリシーは、アテステーションレポートで提供されたクレームを RVPS データベースに登録されている参照値と比較します。すべての値が一致する場合にのみ、アテステーションプロセスは成功します。
  2. 以下のコマンドを実行して、アテステーションポリシー 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 サービスを使用しないでください。オンプレミスまたはパブリッククラウド上のローカルキャッシュサービスを使用します。

手順

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

    $ oc apply -f tdx-config.yaml

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
    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
    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": {}
      }
    • 署名検証あり:

      {
        "default": [
            {
            "type": "insecureAcceptAnything"
            }
        ],
        "transports": {
            "<transport>": { 1
                "<registry>/<image>": 2
                [
                    {
                        "type": "sigstoreSigned",
                        "keyPath": "kbs:///default/<type>/<tag>" 3
                    }
                ]
            }
        }
      }
      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

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

    $ oc apply -f resourcepolicy-configmap.yaml
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.