サポートコンソール開発者トライアルの開始お問い合わせ

4.4. Azure での Confidential Containers のデプロイ

OpenShift Sandboxed Containers をデプロイした後に、Microsoft Azure Cloud Computing Services に Confidential Containers をデプロイすることができます。

重要

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

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

クラスターの要件

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

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

  1. Confidential compute attestation Operator をインストールします。
  2. Trustee のルートを作成します。
  3. Confidential Containers フィーチャーゲートを有効にします。
  4. ピア Pod config map を更新します。
  5. KataConfig カスタムリソース (CR) を削除します。
  6. KataConfig CR を再作成します。
  7. Trustee 認証シークレットを作成します。
  8. Trustee config map を作成します。

  9. アテステーションポリシーを設定します。

    1. 参照値を作成します。
    2. アテスしたクライアントのシークレットを作成します。
    3. リソースアクセスポリシーを作成します。
    4. オプション: デフォルトポリシーをオーバーライドする設定アテステーションポリシーを作成します。
    5. TEE が Intel Trust Domain Extensions の場合は、Provisioning Certificate Caching Service を設定します。
  10. KbsConfig CR を作成します。
  11. アテステーションプロセスを確認します。

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

CLI を使用して、Confidential compute attestation Operator を Azure にインストールできます。

前提条件

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

手順

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

    apiVersion: v1
kind: Namespace
metadata:
  name: trustee-operator-system

  2. 次のコマンドを実行して、trustee-operator-system namespace を作成します。 

    $ oc apply -f trustee-namespace.yaml

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

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

  4. 以下のコマンドを実行して Operator グループを作成します。 

    $ oc apply -f trustee-operatorgroup.yaml

  5. 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

  6. 次のコマンドを実行して、サブスクリプションを作成します。 

    $ oc apply -f trustee-subscription.yaml

  7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。 

    $ oc get csv -n trustee-operator-system

    このコマンドが完了するまでに数分かかる場合があります。

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

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

    出力例

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

4.4.2. Trustee のルートの作成

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

前提条件

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

手順

  1. 次のコマンドを実行してエッジルートを作成します。 

    $ oc create route edge --service=kbs-service --port kbs-port \
  -n trustee-operator-system
    注記

    注記: 現在、有効な CA 署名証明書を持つルートのみがサポートされています。自己署名証明書を使用したルートは使用できません。

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

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

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

    $ echo $TRUSTEE_HOST

    出力例

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

    ピア Pod Config Map のこの値を記録します。

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

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

手順

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

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

  2. 以下のコマンドを実行して config map を作成します。 

    $ oc apply -f cc-feature-gate.yaml

4.4.4. ピア Pod の更新 config map

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

注記

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

手順

  1. Azure インスタンスから以下の値を取得します。

    1. Azure リソースグループを取得して記録します。 

      $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""

    2. Azure VNet 名を取得し、記録します。 

      $ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)

      この値は、Azure サブネット ID を取得するために使用されます。

    3. 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\""

    4. 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\""

    5. Azure リージョンを取得して記録します。 

      $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""

  2. 以下の例に従って 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" 1
  AZURE_INSTANCE_SIZES: "Standard_DC2as_v5,Standard_DC4as_v5,Standard_DC8as_v5,Standard_DC16as_v5" 2
  AZURE_SUBNET_ID: "<azure_subnet_id>" 3
  AZURE_NSG_ID: "<azure_nsg_id>" 4
  PROXY_TIMEOUT: "5m"
  AZURE_IMAGE_ID: "<azure_image_id>" 5
  AZURE_REGION: "<azure_region>" 6
  AZURE_RESOURCE_GROUP: "<azure_resource_group>" 7
  DISABLECVM: "false"
  AA_KBC_PARAMS: "cc_kbc::https://${TRUSTEE_HOST}" 8
  ENABLE_SECURE_BOOT: "true" 9
    1
    ワークロードでインスタンスサイズが定義されていない場合、この値がデフォルトになります。
    2
    Pod の作成時に指定できるすべてのインスタンスサイズを一覧表示します。これにより、メモリーと CPU をあまり必要としないワークロードには小さいインスタンスサイズを定義したり、ワークロードが大きい場合は大きいインスタンスサイズを定義したりすることができます。
    3
    取得した AZURE_SUBNET_ID 値を指定します。
    4
    取得した AZURE_NSG_ID 値を指定します。
    5
    オプション: デフォルトでは、この値は、クラスターの認証情報に基づく Azure イメージ ID を使用して KataConfig CR を実行するときに入力されます。独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。
    6
    取得した AZURE_REGION 値を指定します。
    7
    取得した AZURE_RESOURCE_GROUP 値を指定します。
    8
    Trustee ルートのホスト名を指定します。
    9
    true を指定すると、デフォルトでセキュアブートが有効になります。

  3. 以下のコマンドを実行して config map を作成します。 

    $ oc apply -f peer-pods-cm.yaml

  4. 次のコマンドを実行して、peerpodconfig-ctrl-caa-daemon デーモンセットを再起動します。 

    $ oc set env ds/peerpodconfig-ctrl-caa-daemon \
  -n openshift-sandboxed-containers-operator REBOOT="$(date)"

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

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

KataConfig CR を削除すると、ランタイムと関連リソースがクラスターから削除されます。

重要

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

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

前提条件

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

手順

  1. 次のコマンドを実行して、KataConfig CR を削除します。 

    $ oc delete kataconfig example-kataconfig

    OpenShift Sandboxed Containers Operator は、クラスターでランタイムを有効化するために初期に作成されていたリソースをすべて削除します。

    重要

    KataConfig CR を削除すると、すべてのワーカーノードが再起動するまで CLI は応答を停止します。検証を実行する前に、削除プロセスを完了する必要があります。

  2. 以下のコマンドを実行して、カスタムリソースが削除されたことを確認します。 

    $ oc get kataconfig example-kataconfig

    出力例

    No example-kataconfig instances exist

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

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

重要

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

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

前提条件

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

手順

  1. 以下の例に従って 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')。

  2. 次のコマンドを実行して、KataConfig CR を作成します。 

    $ oc apply -f example-kataconfig.yaml

    新しい KataConfig CR が作成され、ワーカーノードに kata-remote がランタイムクラスとしてインストールされます。

    インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

  3. 次のコマンドを実行して、インストールの進行状況を監視します。 

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

    kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata はクラスターにインストールされます。

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

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

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

    $ oc get runtimeclass

    出力例

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

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

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

前提条件

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

手順

  1. 次のコマンドを実行して、秘密鍵を作成します。 

    $ openssl genpkey -algorithm ed25519 > privateKey

  2. 次のコマンドを実行して、公開鍵を作成します。 

    $ openssl pkey -in privateKey -pubout -out publicKey

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

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

  4. 次のコマンドを実行してシークレットを確認します。 

    $ oc get secret -n trustee-operator-system

4.4.8. Trustee config map の作成

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

前提条件

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

手順

  1. 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"
      }
    }

  2. 以下のコマンドを実行して config map を作成します。 

    $ oc apply -f kbs-config-cm.yaml

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

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

参照値

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

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

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

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

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

アテステーションポリシー
オプション: 独自の設定アテステーションポリシーを作成して、デフォルトの設定アテステーションポリシーを上書きできます。
TDX の Provisioning Certificate Caching Service

TEE が Intel Trust Domain Extensions (TDX) である場合は、Provisioning Certificate Caching Service (PCCS) を設定する必要があります。PCCS は、Provisioning Certification Key (PCK) 証明書を取得し、ローカルデータベースにキャッシュします。

重要

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

手順

  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

  3. 次の例に従って、アテストされたクライアントと共有する 1 つ以上のシークレットを作成します。 

    $ oc create secret generic kbsres1 --from-literal key1=<res1val1> \
  --from-literal key2=<res1val2> -n trustee-operator-system

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

  4. 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 がサンプルのアテスターでない場合にすべてのリソースを取得できます。

  5. 次のコマンドを実行して、リソースポリシーの config map を作成します。 

    $ oc apply -f resourcepolicy-configmap.yaml

  6. オプション: 次の例に従って、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 データベースに登録されている参照値と比較します。すべての値が一致する場合にのみ、アテステーションプロセスは成功します。

  7. 以下のコマンドを実行して、アテステーションポリシー config map を作成します。 

    $ oc apply -f attestation-policy.yaml

  8. TEE が Intel TDX の場合は、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/)。

  9. 以下のコマンドを実行して TDX config map を作成します。 

    $ oc apply -f tdx-config.yaml

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

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

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

手順

  1. 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

  2. 以下のコマンドを実行して KbsConfig CR を作成します。 

    $ oc apply -f kbsconfig-cr.yaml

検証

  1. 次のコマンドを実行して、デフォルトのプロジェクトを設定します。 

    $ oc project trustee-operator-system

  2. 次のコマンドを実行して 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

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

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

  4. 次のコマンドを実行して、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

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

テスト Pod を作成し、そのシークレットを取得することで、アテステーションプロセスを検証できます。

重要

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

デフォルトでは、Pod 仮想マシンイメージに埋め込まれたエージェント側のポリシーにより、Confidential Containers Pod の exec API と log API が無効になります。このポリシーにより、機密データが標準の I/O に書き込まれないようにします。

テストシナリオでは、ポリシーアノテーションを Pod に追加することで、実行時に制限をオーバーライドできます。テクノロジープレビューの場合、ランタイムポリシーアノテーションはリモートアテステーションによって検証されません。

前提条件

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

手順

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

    apiVersion: v1
kind: Pod
metadata:
  name: ocp-cc-pod
  labels:
    app: ocp-cc-pod
  annotations:
    io.katacontainers.config.agent.policy: cGFja2FnZSBhZ2VudF9wb2xpY3kKCmRlZmF1bHQgQWRkQVJQTmVpZ2hib3JzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgQWRkU3dhcFJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENsb3NlU3RkaW5SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBDb3B5RmlsZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENyZWF0ZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IENyZWF0ZVNhbmRib3hSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBEZXN0cm95U2FuZGJveFJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IEV4ZWNQcm9jZXNzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgR2V0TWV0cmljc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IEdldE9PTUV2ZW50UmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgR3Vlc3REZXRhaWxzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgTGlzdEludGVyZmFjZXNSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBMaXN0Um91dGVzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgTWVtSG90cGx1Z0J5UHJvYmVSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBPbmxpbmVDUFVNZW1SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBQYXVzZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFB1bGxJbWFnZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFJlYWRTdHJlYW1SZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZW1vdmVDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZW1vdmVTdGFsZVZpcnRpb2ZzU2hhcmVNb3VudHNSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZXNlZWRSYW5kb21EZXZSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBSZXN1bWVDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBTZXRHdWVzdERhdGVUaW1lUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU2V0UG9saWN5UmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU2lnbmFsUHJvY2Vzc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFN0YXJ0Q29udGFpbmVyUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU3RhcnRUcmFjaW5nUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgU3RhdHNDb250YWluZXJSZXF1ZXN0IDo9IHRydWUKZGVmYXVsdCBTdG9wVHJhY2luZ1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFR0eVdpblJlc2l6ZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUNvbnRhaW5lclJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUVwaGVtZXJhbE1vdW50c1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZUludGVyZmFjZVJlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFVwZGF0ZVJvdXRlc1JlcXVlc3QgOj0gdHJ1ZQpkZWZhdWx0IFdhaXRQcm9jZXNzUmVxdWVzdCA6PSB0cnVlCmRlZmF1bHQgV3JpdGVTdHJlYW1SZXF1ZXN0IDo9IHRydWUK 1
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
    1
    この Pod アノテーションは、機密データが標準 I/O に書き込まれないようにするポリシーをオーバーライドします。

  2. 以下のコマンドを実行して Pod を作成します。 

    $ oc create -f verification-pod.yaml

  3. 次のコマンドを実行して、ocp-cc-pod の Bash シェルに接続します。 

    $ oc exec -it ocp-cc-pod -- bash

  4. 次のコマンドを実行して Pod シークレットを取得します。 

    $ curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1

    出力例

    res1val1

    Trustee サーバーは、証明書が成功した場合にのみシークレットを返します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.