auths サブセクション

auths セクションは、コンテナーのレジストリーに関する情報で構成されます。 契約でパブリック・イメージを使用する場合、資格情報は必要ないため、 auths セクションは必要ありません。 auths サブセクションは、コンテナー・イメージがプライベートである場合にのみ必要です。 以下の例に示すように、このサブセクションにはイメージ情報はありません。 このサブセクションには、イメージ・レジストリーの名前と資格情報 (同じものの username-password など) を含める必要があります。 キーはホスト名である必要がありますContainer Registryまたは、デフォルトの Docker レジストリの場合は次の文字列:

https://index.docker.io/v1/

以下のスニペットは、 IBM Cloud レジストリーの例を示しています。 API キーの使用について詳しくは、 クライアント・ソフトウェアを使用した自動化での認証 を参照してください。

auths:
  us.icr.io:
    password: <apikey>
    username: iamapikey

compose サブセクション

これは、アーカイブ・サブセクションで構成されます。 アーカイブ・サブセクションには、 docker-compose.yaml ファイルの Base64 エンコード TGZ ファイル・アーカイブが含まれています。 Hyper Protect Container Runtime イメージは Docker Engine および Docker Compose を使用してコンテナーを開始するため、最初に標準の docker-compose ファイルを使用してコンテナーに関する情報を作成する必要があります。 このファイルはアーカイブされ、 Base64 エンコードされ、このプロセスの出力は、コンポーズセクション内のアーカイブサブセクションの値として提供されます。 詳しくは、 Docker Composeの概要 を参照してください。

docker-compose ファイルのボリューム情報の下に指定されているマウント・ポイントは、契約のワークロード・セクションに指定されているボリューム・マウント・ポイントと整合している可能性があります。

Docker Compose ファイルの一部としてビルドを実行することはサポートされていません。 Docker Compose ファイルに build セクションがないことを確認します。

docker-compose ファイルでは、「yaml」形式と「yml」形式の両方がサポートされます。 Docker Compose ファイルの例を以下に示します。

version: '3'
services:
  nginx:
    image: nginx@sha256:e73ba8654ba7fd1834e78a3d4e9d72ffaaa3372d42996af5c34ba3e1abc293e8
    privileged: true
    user: 0:0
    restart: always
    ports:
    - 80:80

ワークロードセクションが事前に暗号化されている場合、レジストリが不明であるというユースケースが存在します。 例えば、ワークロードプロバイダーがデプロイヤーにレジストリミラーやプライベートレジストリの使用を許可したい場合、レジストリとプル認証 Container Registry 情報を動的に上書きすることが可能です。 この作業は、作業負荷の提供者と展開者の間で調整する必要があります。 詳しくは、 動的レジストリー・リファレンスの使用 を参照してください。

以下の手順を完了してBase64エンコードされたアーカイブ ファイル。 のBase64出力はcompose.b64ファイル。 <COMPOSE_Folder> に移動して、以下のコマンドを実行します。

tar czvf compose.tgz docker-compose.yml

base64 -w0 compose.tgz > compose.b64

Compose tgz ファイルにはディレクトリと通常のファイルのみが含まれていることを確認します。 リンクまたはパイプはサポートされていません。

compose.b64 の内容を compose-> archive の値としてコピーします。

compose:
  archive: <paste the content of compose.b64 >

この例の場合、以下の出力のような応答が表示されます。

compose:
  archive: H4sIAKOFmGIAA+2RTW6DMBBGs84pRuyB8Q8k+DIRwZOGtmBkkyrcvhgnLVVV1EWkqhJv4ZHt8ednWZvqhWxcmaYzjpKhed08HETMpQRfd3k2VeRhPpEJCUxymTPkIuOALBOIG8DHq3zn4vrSjiqdLY/nsv+xb2w7nRZywlPgo/4THNm3uiKntgCWdO1aowmZnwLUTflECpwo8Jpu9NyZ2zvQgdADFEudoXyQzSu+fPPzseSvedo6qjV7mDa2anZbdH8totL6somtUlvX8K4SJshDsFKU2NmFvAZuMc9U37wceeys+Y6BI8Fi6+6vxK5RS+YFDh6RNu//tuVlZWVJd4BcjKckQAIAAA=

play サブセクション

の中に play サブセクションでは、ワークロードを次のように定義できます。ポッド記述子。 各ポッドには、1 つ以上のコンテナー定義を含めることができます。 記述子は、以下のいずれかの方法で指定できます：

• play の resources サブセクション内のプレーン YAML 形式。 このセクションは記述子の配列であり、 ポッド と ConfigMapsの 2 つのタイプの記述子をサポートします。

  以下の例は、 resources セクションの使用方法を示しています。

  workload: |
    type: workload
    play:
      resources:
        - apiVersion: v1
          kind: Pod
          metadata:
            name: busybox
          spec:
            containers:
            - name: main
              image: ...
              command:
              - printenv
              envFrom:
              - configMapRef:
                  name: contract.config.map
                  optional: false
            restartPolicy: Never
  

  次の例は、 resources セクションを使った initcontainers の使い方を示している：

  workload: |
    type: workload
    play:
      resources:
        - apiVersion: v1
          kind: Pod
          metadata:
            name: busybox
          spec:
            initContainers:
            - name: attest
              image: ...
              volumeMounts:
              - mountPath: /var/hyperprotect
                name: datavolume
            containers:
            - name: main
              image: ...
              command:
              - printenv
              envFrom:
              - configMapRef:
                  name: contract.config.map
                  optional: false
            restartPolicy: Never
  

• の中に archive のサブセクション play、アーカイブはBase64エンコードされ、gzip 圧縮された tar ファイル。 ポッドまたは ConfigMaps は、この tar ファイルの最上位にある YAML ファイルとして表されます。 ファイルには余分なファイルが含まれている可能性があり、すべてのファイルがホストファイルシステムに抽出された後に、Podが起動されます。 現行作業ディレクトリー は、ファイルが抽出されたディレクトリーであるため、相対パスを指定したボリューム・マウントを使用して、YAML ファイルからファイルまたはディレクトリーをマウントすることができます。

  次に例を示します。

  workload: |
    type: workload
    play:
      archive: ${COMPOSE_VALUE}
    auths:
      us.icr.io:
        username: iamapikey
        password: Eqx0TS....
    volumes:
      test-volume:
        mount: /var/hyperprotect
        seed: "workload_phrase"
        filesystem: ext4
  

• play の templates サブセクション内のテンプレート・フォーマット。 このセクションは、YAML 形式の記述子の配列です。 ポッドまたはConfigMaps 記述子を記述する時点で不明な可変性ポイント（POV）を持つことがあります。 これらのPOV はテンプレートとして表現することができ、値は契約上の情報からデプロイ時に完成されます。 go templates をテンプレート構文として使用します。これは、 helm チャートで使用されるものと同じであるため、テンプレートを k8sと簡単に交換できます。 以下の Built-In オブジェクトをサポートします。

  • 環境: このオブジェクトには、ワークロードと環境セクションの間でマージされた環境変数が含まれます。 オブジェクトは {{ .Env }} として使用可能です。

  次に例を示します。

  workload: |
    type: workload
    auths:
     docker.io:
      password: <password>
      username: test
    play:
      templates:
        - apiVersion: v1
          kind: Pod
          metadata:
            name: busybox
          spec:
            initContainers:
            - name: initcontainer
              image: docker.io/library/init-config@sha256:b1306efee704017b0e02efadc011d374063a4e9c47b86bdc57744fc3f0666383
            containers:
            - name: main
              image: "{{ .Env.REGISTRY }}/hpse-docker-busybox-s390x@sha256:732efa374f1e6c964caeacab0bcb370385ee386041a14d4a32176462e3f75c7b"
              command:
              - printenv
              envFrom:
              - configMapRef:
                  name: contract.config.map
                  optional: false
            restartPolicy: Never
  env: |
    type: env
    logging:
      logRouter:
        hostname: 34be57c7-6ff2-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com
        iamApiKey: <iamApiKey of the service instance> / xxxx
        port: 443
    env:
      REGISTRY: docker-io/test
  

  {{ .Env REGISTRY }} 式は、この例で契約の env セクションに定義されている REGISTRY 環境変数を参照します。

  テンプレートは有効な YAMLである必要があるため、置換式がストリングの最初の部分として出現する場合はエスケープする必要があります。 そうでなければ、ブロックマッピング構文。 これは、モデル表現ではなくドキュメントのテキスト表現に式が適用される ヘルムテンプレートとは異なります。

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: main
    image: ...
    command:
    - printenv
    envFrom:
    - configMapRef:
        name: contract.config.map
        optional: false
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: main
    image: ...
    volumeMounts:
    - name: test-volume
      readOnly: true
      mountPath: /fromHost
  volumes:
  - name: test-volume
    hostPath:
      path: /var/hyperprotect
      type: Directory
  restartPolicy: Never

images サブセクション

Docker は、 Docker コンテンツ・トラスト（DCT ）の退任を発表した。 DCTはレガシーな Notary v1 フレームワーク上に構築されていますが、このフレームワークは現在アクティブに保守されていないため、画像署名と検証のための将来対応可能な、または持続可能なソリューションとは考えられていません。 その結果、顧客はDCTから移行し、現在のサプライチェーンセキュリティ標準に沿った OCI準拠の画像署名・検証技術を採用することが推奨される。 コンテナイメージを IBM Cloud Container Registry (ICR) に移行できる。 ICRは、 Red Hat Signing Service (RHS) を信頼できる署名ルートとして統合し、ベンダーに裏付けされた信頼モデルを提供し、現代のコンテナ・セキュリティとサプライチェーンのベスト・プラクティスとの整合を図っている。 詳しくは、 Docker コンテンツ・トラストを引退する を参照。

images サブセクションは、署名されたイメージのみを対象としています。

<container registry>/<username or namespace>/<image name>
eg- us.icr.io/mynamespace/my-haproxy:

notary: "https://notary.us.icr.io"

cat ~/.docker/trust/tuf/us.icr.io/<username>/<imagename>/metadata/root.json

images:
  dct:
    us.icr.io/mynamespace/my-haproxy:
      notary: "https://notary.us.icr.io"
      publicKey: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJpRENDQVM2Z0F3SUJBZ0lSQUxCMXBPYlpEQlRRc09GSFlxazMzaWd3Q2dZSUtvWkl6ajBFQXdJd0tqRW8KTUNZR0ExVUVBeE1mZFhNdWFXTnlMbWx2TDNCeVlXSm9ZWFF4TWpNdmJYa3RhR0Z3Y205NGVUQWVGdzB5TWpBMApNVE14TURFd01ETmFGdzB6TWpBME1UQXhNREV3TUROYU1Db3hLREFtQmdOVkJBTVRIM1Z6TG1samNpNXBieTl3CmNtRmlhR0YwTVRJekwyMTVMV2hoY0hKdmVIa3dXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU1AKWGsrelE2MlFZNjI3MWQ1cTBMZHY3SGc3QzZkMGZOUlRsQmJXekhOWWFDZzlpU0piYnVNdjVBY0JmMjlqQi83eApqYzhzVitxMksyemtkTHV4QWxGWm96VXdNekFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJCkt3WUJCUVVIQXdNd0RBWURWUjBUQVFIL0JBSXdBREFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUIzd0JTa0IxaXAKZHZZYlBMbFBmS3RZT0hsYnZzUllKa0FZM2hnY0xuNWhwQUloQUt6cmhsU3p4K1I5bmdtMTBlZVkyaFNCRmgrawpMWHp6SFkwaktTVzhyM1FhCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

services:
  <imagename>:
    image: s390x/redis@sha256:db467ab5c53bdeef65762a7534e26fecb94a0f218bd38afd2eaba1a670c472b1

gpg -a --export ${KEY_ID}|base64 -w0

images:
  rhs:
      OCI-image-identifier:
        publicKey: abcdef

workload- volumes サブセクション

契約で volumes セクションを指定する必要があるのは、作成時にデータ・ボリュームがインスタンスに接続されている場合のみです。 このセクションで提供される情報は、ユーザーが提供した添付データボリュームのマウントに使用され、その後、 workload および env セクションで提供された「種」を使用して暗号化されます。 「マウント」フィールドには、任意のパスを指定できます。 ユーザーが指定したパスは、データボリュームのマウントに内部的に使用されます。 契約で指定されたマウントパスは、 docker-compose.yaml ファイルのボリュームセクションで指定されたパスと一致する必要があります。これにより、コンテナのワークロードに関連付けられたすべてのデータがこのデータボリュームに保存されます。

volumes サブセクションは、ユーザー提供のシードを使用したデータ・ボリュームの自動暗号化をサポートしています。 データ・ボリュームが Hyper Protect Virtual Servers インスタンスに接続されている場合、そのデータ・ボリュームは、契約の volumes サブセクションの「seed」フィールドで指定されたシードを使用して自動的に暗号化されます。 したがって、2 つのシードを指定する必要があります。1 つは workload セクションを介して (ワークロード・ペルソナによって) 提供され、もう 1 つは env セクションを介して (デプロイヤー・ペルソナによって) 提供されます。 これらの 2 つのシードは、内部的に UTF8 シーケンスに変換されてから、連結されます。 その後、連結シーケンスのハッシュ (SHA256) が 16 進ダイジェストとして計算されます。これは、データ・ボリュームを暗号化するための LUKS パスフレーズとして使用されます。

現在、 env と workload のシードには、 最低3文字の長さが必要です。 2026年3月以降、この最低文字数は15文字に引き上げられる。 2026年3月以降に 15文字より短いシード値を使用すると、エラーまたはデプロイメントに失敗する可能性があります。 中断を避けるため、できるだけ早くすべてのシード値を少なくとも 15 文字の長さに更新してください。 ルールは以下のセクションで定義されている。

2026年3月以降、タネを作るには以下のルールに従わなければならない：

• スペースは使用できません。
• 少なくとも 15。 以下は使用可能な文字である：
  • 小文字 (a-z)
  • 大文字 (A-Z)
  • 数値 (0-9)
  • 特殊文字 !@#$%^&*(),.?":{}|<>_-

hexdigest の妥当性を確認するには、次のコマンドを使用できます：

echo -n "seed1seed2" | sha256sum

ここでは、契約のワークロード・セクションで「シード」を指定する方法について説明します。 env セクションを通じて「シード」入力を提供する方法について詳しくは、 env セクション を参照してください。 暗号化のために両方のシードを指定する必要があります。 インスタンスがシャットダウンしたシードが 1 つのみの場合、暗号化は失敗します。

データを保存状態において、より高度な暗号化保護と制御を追加するには、との統合により実現 Hyper Protect Crypto Services できます。 から開始し、 ibm-hyper-protect-container-runtime-1-0-s390x-11 を第三のシードとしてランダム値を生成 Hyper Protect Crypto Services し、ルートキーでラップすることができます。 LUKS パスフレーズは、 3 つ のシード (メタデータ・パーティション内のシードとコントラクトからの 2 つのシード) を使用して生成されます。 詳しくは、データの保護を参照してください。

以下のスニペットは、volumes セクションの例です。

volumes:
  test:
    filesystem: ext4
    mount: /mnt/data
    seed: "workload_phrase"

HPCRイメージバージョンから ibm-hyper-protect-container-runtime-1-0-s390x-9、新しいVPC Hyper Protect Virtual Servers インスタンスでは、データボリュームが2つの部分に分割されます。 最初のパーティション（ 100Mib ）は内部メタデータ用に予約されています。2番目のパーティションはワークロード用のデータボリュームとして残ります。 新規ボリュームのみがパーティション化され、古いバージョンの HPCR イメージではパーティション化されたボリュームを使用できません。 既存の暗号化ボリュームを使用したプロビジョニングも機能します。 違いは、既存のボリュームがパーティション化されないことです。このボリュームを使用して古いイメージに戻ることもできます。

ibm-hyper-protect-container-runtime-1-0-s390x-12 以降、デプロイヤーとプロバイダーは「シードのローリング」機能を使用できます。 シードをロールまたはローテーションしてセキュリティー態勢を強化するオプションが提供されています。また、シードが暗号漏えいした場合も提供されます。 デプロイヤーまたはプロバイダー、あるいはその両方がシードをロールする場合は、現在のシード情報を previousSeed パラメーターに指定し、新しいシード情報を seed パラメーターに指定する必要があります。

以下のスニペットは、volumes セクションの例です。

volumes:
  test:
    filesystem: ext4
    mount: /mnt/data
    seed: "workload_phrase1"
    previousSeed: "workload_phrase"

ibm-hyper-protect-container-runtime-1-0-s390x-13 以降、仮想サーバー・インスタンスを立ち上げるときに複数のボリュームを接続できるようになりました。 インスタンスが実行中の際に追加されたボリュームは無視されます。

以下のスニペットは、volumes セクションの例です。

volumes:
  test1:
    filesystem: "ext4"
    mount: "/mnt/data"
    seed: "seed_value_with_minimum_15_characters"
  test2:
    filesystem: "ext4"
    mount: "/mnt/test2"
    seed: "seed_value_with_minimum_15_characters"
  test3:
    filesystem: "ext4"
    mount: "/mnt/test3"
    seed: "seed_value_with_minimum_15_characters"

logging サブセクション

 env:
   logging:
     logRouter:
       hostname: <host name of the service instance> /
       iamApiKey: <iamApiKey of the service instance> / xxxx
       port: <port of the service instance(443)

env- volumes サブセクション

このセクションを続行する前に、ワークロード・セクションの workload-volumes サブセクションをお読みください。 前述のように、接続されたデータ・ボリュームの自動ディスク暗号化の場合は、2 つのカスタマー・シードを指定する必要があります。1 つは workload- volumes サブセクションに、もう 1 つは env- volumes サブセクションに指定します。 シードは、任意のランダム・テキストにすることができます。

env- volumes のサブセクションの例をご覧ください

volumes:
  test:
    seed: "seed_value_with_minimum_15_characters"

「シードのローリング」機能を使用する場合は、以下のスニペットを例として使用できます。

volumes:
  test:
    seed: "seed_value_with_minimum_15_characters"
    previousSeed: "env_phrase12345"

複数のボリュームを使用する場合、デプロイヤーはボリュームが事前に作成されていることを確認する必要があります。また、契約ファイルにボリューム ID を指定する必要もあります。 それ以外の場合は、ボリューム名を指定し、同じ名前でボリュームを作成する必要があります。 両方が指定されていない場合、ボリュームキーがボリューム名と見なされ、仮想サーバーインスタンスの作成中または作成前に、同じ名前でボリュームを作成する必要があります。 以下のスニペットはその一例です：

 env: |
   logging:
     logRouter:
       hostname: 34be57c7-6ff2-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com
       iamApiKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
       port: 443
   volumes:
     test1:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       volumeID: "r006-f7b44467-01af-xxx-xxxx-xxxxxxx"
       seed: "seed_value_with_minimum_15_characters"
     test2:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       volumeName: "volume2"
       seed: "seed_value_with_minimum_15_characters"
     test3:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       seed: "seed_value_with_minimum_15_characters"

ここで、

• ボリューム名：VPC上でボリュームを作成した際に指定した名前です。
• ボリューム ID: 作成されたボリュームのシステム生成ボリューム ID です。
• ボリューム・キー: 各ボリュームの固有のボリューム名です。

ボリュームキーは 、ワークロードのボリュームサブセクション のキーと同じでなければなりません。

前述のように、 Hyper Protect Crypto Services と統合して、3 番目のシードを生成し、ルート鍵でラップすることができます。 以下の例を参照してください。 詳しくは、データの保護を参照してください。

volumes:
 test:
   kms:
     - apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       crn: "crn:v1:bluemix:public:hs-crypto:us-south:a/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
       type: "public"
     - apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       crn: "crn:v1:bluemix:public:hs-crypto:us-south:a/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
       type: "private"
   seed: "seed_value_with_minimum_15_characters"
   apiKey: "**********************"
   kmsTimeout: 10

signingKey サブセクション

signingKey の使用方法に関する詳細については、「 契約の署名 」を参照してください。

env サブセクション

• ポッド記述子が workload セクションで使用されている場合は、以下のようにします。

  play サブセクション のテンプレート形式の例を参照してください。

• workload セクションで docker compose ファイルを使用する場合は、以下のようにします。

  Docker Compose ファイルに環境セクションがある場合は、以下のスニペットを例として使用できます。

  environment:
    KEY1: "${Value1}"
    KEY2: "${Value2}"
  

  Docker Composeファイルに環境セクションがある場合、前述の例のように、デプロイヤーの env セクションで値を渡すことができます。 以下の例は、 env 変数の値を指定する方法を示しています。

  env:
   value1: "abc"
   value2: "xyz"
  

暗号化証明書のダウンロードと公開鍵の抽出

1. 証明書をダウンロードします。 以下の表は、イメージのバージョンごとに、暗号化証明書の有効期限およびイメージの非推奨日／廃止日を一覧にしたものです。

注

• Deprecated- イメージを使用して IBM Cloud CLI からインスタンスを作成できます。 非推奨ステータスは、そのステータスがobsoleteに変更される前に、イメージの使用を思いとどまらせることができます。 イメージカタログは、常に最新の2つのイメージバージョンを保持します： n と n-1。 新しいバージョン( n+1 )が利用可能になると、システムは最も古いバージョン( n-1 )を非推奨とする。
• 廃止 ：イメージに関連付けられた証明書の有効期限が切れると、そのイメージはインスタンスのプロビジョニングに利用できなくなります。
• 必ずイメージに対応する暗号化証明書をダウンロードし、契約を暗号化する。

イメージの非推奨状況または廃止状況を確認するには、 IBM Cloud イメージ・リスト・コマンドを使用することもできます。

イメージの状況を取得するためのイメージ・リスト・コマンドについては、 資料 を参照してください。

2. 契約の暗号化証明書の検証トピック の手順に従って、暗号化証明書を検証します。

契約の暗号化された workload セクションの作成

契約の任意のセクションの値は、プレーン・テキストにすることも、暗号化することもできます。 契約で使用されるワークロードセクションを暗号化するには、 Ubuntu システム上で以下の手順を完了してください

1. ワークロード要件に基づいて docker-compose.yaml ファイルを作成します。 以下に例を示します。

   services:
     redisnode01:
       image: s390x/redis@sha256:db467ab5c53bdeef65762a7534e26fecb94a0f218bd38afd2eaba1a670c472b1
       ports:
         - "6379:6379"
   

   詳しくは、 Docker Composeの概要 を参照してください。

2. 契約の ワークロード・セクション を作成し、 workload.yaml ファイルに内容を追加します。

   以下は、 ​workload.yaml の例です：

   type: workload
   auths:
     us.icr.io:
      password: ${API_KEY}
      username: iamapikey
   compose:
    archive: ${COMPOSE_VALUE}
   volumes:
    test0:
      mount: "/mnt/data"
      seed: "workload_seed12"
      filesystem: "ext4"
    env:
      key: "value"
   

3. workload.yaml ファイルと ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt の完全パスをエクスポートします。

   WORKLOAD="<PATH to workload.yaml>"
   CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt>"
   

4. 次のコマンドを使用して、ランダムなパスワードを作成してください。 契約は、ランダムなパスワードと対称AESによって暗号化される。

   PASSWORD="$(openssl rand 32 | base64 -w0)"
   

5. OpenSSL 3.0 以降、 OpenSSL rsautl サブコマンドは非推奨となり、 pkeyutl サブコマンドに置き換えられる。 パスワードを ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt で暗号化するには、以下のコマンドのいずれかを使用する：

   • rsautl を使用（非推奨）：

      ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl rsautl -encrypt -inkey $CONTRACT_KEY -certin | base64 -w0)"
   

   • pkeyutl （推奨）：

     ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl pkeyutl -encrypt -inkey $CONTRACT_KEY -certin -pkeyopt rsa_padding_mode:pkcs1 | base64 -w0)"
     

6. 以下のコマンドを使用して、ランダム・パスワードで workload.yaml ファイルを暗号化します。

   ENCRYPTED_WORKLOAD="$(echo -n "$PASSWORD" | base64 -d | openssl enc -aes-256-cbc -pbkdf2 -pass stdin -in "$WORKLOAD" | base64 -w0)"
   

7. 契約の暗号化されたセクションを取得するには、以下のコマンドを使用します。

   echo "hyper-protect-basic.${ENCRYPTED_PASSWORD}.${ENCRYPTED_WORKLOAD}"
   

8. ステップ 7 の出力を取得し、 user-data.yaml ファイルに追加します。

   workload: hyper-protect-basic.js7TGt77EQ5bgTIKk5C0pViFTRHqWtn..............
   

   接頭部 hyper-protect-basic は必須です。

契約の暗号化された env セクションの作成

契約書で使用される env セクションを暗号化するには、 Ubuntu システムで以下の手順を完了してください

1. 契約の env セクション を作成し、 env.yaml ファイルに内容を追加します。

   以下は、 env.yaml の例です：

   type: env
     logging:
     syslog:
       hostname: ${RSYSLOG_SERVER_IP}
       port: 6514
       server: "${RSYSLOG_SERVER_ROOT_CA}"
       cert: "${RSYSLOG_CLIENT_CA}"
       key: "${RSYSLOG_CLIENT_KEY}"
     volumes:
       test0:
         seed: "stsolutiontest1"
   

2. env.yaml ファイルと ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt の完全パスをエクスポートします。

   ENV="<PATH to env.yaml>"
   CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt>"
   

3. ランダムなパスワードを作成するには、次のコマンドを実行してください：

   PASSWORD="$(openssl rand 32 | base64 -w0)"
   

4. OpenSSL 3.0 以降、 OpenSSL rsautl サブコマンドは非推奨となり、 pkeyutl サブコマンドに置き換えられる。 パスワードを ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt で暗号化するには、以下のコマンドのいずれかを使用する：

   • rsautl (非推奨）：

      ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl rsautl -encrypt -inkey $CONTRACT_KEY -certin | base64 -w0)"
   

   • pkeyutl (推奨）：

     ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl pkeyutl -encrypt -inkey $CONTRACT_KEY -certin -pkeyopt rsa_padding_mode:pkcs1 | base64 -w0)"
     

5. 以下のコマンドを使用して、ランダム・パスワードで env.yaml を暗号化します。

   ENCRYPTED_ENV="$(echo -n "$PASSWORD" | base64 -d | openssl enc -aes-256-cbc -pbkdf2 -pass stdin -in "$ENV" | base64 -w0)"
   

6. 契約の暗号化されたセクションを取得するには、以下のコマンドを使用します。

   echo "hyper-protect-basic.${ENCRYPTED_PASSWORD}.${ENCRYPTED_ENV}"
   

7. ワークロード・セクションを暗号化するには、 契約の「暗号化された workload の作成」セクション を参照してください。

8. ステップ 6 の出力を取得し、それを user-data.yaml ファイルに追加します。

   env: hyper-protect-basic.VWg/5/SWE+9jLfhr8q4i.........
   

暗号化および認証証明書の期限切れ警告ログ

HPVS は、設定されたロギング・サービスに、暗号化証明書と認証証明書の期限切れと期限切 れに関する警告メッセージを記録します。

通知スケジュールは以下の通り：

• 有効期限の30日前 ： 24時間に 1回、証明書の有効期限が1カ月後に切れることを知らせる警告メッセージが表示される。

  次に例を示します。

  HPL12011W: The Encryption certificate is going to expire -> Warning: The encryption certificate will expire on 12 February 2026 at 16:17:41 UTC, over 20 days. Upgrade to the latest image to unlock the latest features and avoid potential security vulnerabilities!!!
  

• 有効期限の7日前 ：有効期限が近づくと 12時間ごとに警告メッセージが記録され、対策の必要性が強調されます。

  次に例を示します。

  HPL12011W: The Encryption certificate is going to expire -> Warning: The encryption certificate will expire on 27 January 2026 at 16:17:41 UTC, over 4 days. Upgrade to the latest image to unlock the latest features and avoid potential security vulnerabilities!!!
  

• 証明書の期限切れ後証明書の有効期限が切れた場合、HPVS イメージがアップグレードされるまで、HPVS は 4 時間ごとに警告メッセージを記録します。

  次に例を示します。

  HPL12013W: The Encryption certificate expired -> Urgent: The encryption certificate expired on 15 June 2025 at 17:15:59 UTC, over 7 months. Immediate upgrade to the latest image is required to unlock the latest features and prevent serious security breaches.
  

1. ロギング・インスタンスの詳細を取得する

IBM Log Analysis または汎用 syslog バックエンドを使用してロギングを構成できます。 この例では、 IBM Log Analysisを使用します。 さまざまなプランからお選びいただけます。 ホスト名やインジェクションキーなどの必要な詳細情報を取得する方法については、 VPCの Hyper Protect Virtual Servers のログ を参照してください。

2. env セクションを作成します。

プレーンテキストの契約書を使用している場合は、パイプ記号「|」を書き漏らさないようにしてください。 セクションの暗号化を計画している場合は必要ありません。

env: |
  type: env
  logging:
    logRouter:
      hostname: 34be57c7-6ff2-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com
      iamApiKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      port: 443

3. docker-compose ファイルを準備します。

ロギングの詳細があると仮定して、単純な Docker Compose ファイルを見つけます。 次の例では、 NGINX コンテナを公開している。 例を参考に docker-compose.yaml。

services:
  nginx:
    image: docker.io/library/nginx@sha256:b1306efee704017b0e02efadc011d374063a4e9c47b86bdc57744fc3f0666383
    ports:
    - 80:80
    - 443:443

4. base64-encoded バージョンの docker-compose ファイルを取得します。

tar -czvf compose.tgz docker-compose.yaml

base64 -i compose.tgz > compose.b64

5. Compose セクションを作成する

  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==

6. ワークロード・セクションへのデータの取り込み

プレーンテキストの契約書を使用している場合は、パイプ記号（|）を必ず入力してください。

workload: |
  type: workload
  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==

7. 簡単な契約の準備ができました

env: |
  type: env
  logging:
    logRouter:
      hostname: 34be57c7-6ff2-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com
      iamApiKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      port: 443
workload: |
  type: workload
  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==