Unterabschnitt auths

Der Abschnitt auths enthält Informationen zur Registry des Containers. Wenn ein öffentliches Image im Vertrag verwendet wird, benötigen Sie den Abschnitt auths nicht, da keine Berechtigungsnachweise erforderlich sind. Der Unterabschnitt auths ist nur erforderlich, wenn die Container-Images privat sind. Dieser Unterabschnitt enthält keine Bildinformationen, wie im folgenden Beispiel gezeigt. Dieser Unterabschnitt muss den Namen der Image-Registry und die Berechtigungsnachweise (z. B. Benutzername/Kennwort) enthalten. Der Schlüssel muss der Hostname des Container Registry oder die folgende Zeichenfolge für das Standard-Docker-Register:

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

Das folgende Snippet zeigt ein Beispiel für IBM Cloud Registry. Weitere Informationen zur Verwendung des API-Schlüssels finden Sie unter Client-Software für die Authentifizierung in der Automatisierung verwenden.

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

Unterabschnitt compose

Sie besteht aus einem Archivunterabschnitt. Der Unterabschnitt 'archive' enthält das mit Base64 codierte TGZ-Dateiarchiv der Datei docker-compose.yaml. Da das Hyper Protect Container Runtime-Image Docker Engine und Docker Compose verwendet, um den Container zu starten, müssen die Informationen zum Container zuerst unter Verwendung einer standardmäßigen Docker Compose-Datei erstellt werden. Diese Datei wird dann archiviert und Base64 verschlüsselt. Das Ergebnis dieses Vorgangs wird als Wert für den Unterabschnitt "Archiv" im Abschnitt "Erstellen" bereitgestellt. Weitere Informationen finden Sie unter Übersicht über Docker Compose.

Die unter den Datenträgerinformationen der Datei 'docker-compose' angegebenen Mountpunkte können an dem Datenträgermountpunkt ausgerichtet sein, der im Abschnitt 'workload' des Vertrags angegeben ist.

Die Ausführung eines Builds als Teil einer Docker Compose-Datei wird nicht unterstützt. Stellen Sie sicher, dass Ihre Docker Compose-Datei keinen Abschnitt build enthält.

Sowohl das Format "yaml" als auch das Format "yml" werden für die Datei "docker-compose" unterstützt. Sehen Sie sich das folgende Beispiel für eine Docker-Compose-Datei an.

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

Es gibt Anwendungsfälle, bei denen das Register nicht bekannt ist, wenn der Workload-Abschnitt vorverschlüsselt ist. Wenn der Workload-Anbieter beispielsweise dem Bereitsteller die Verwendung eines Registrierungsspeegels oder eines privaten zulassen Container Registry möchte, ist es möglich, die Registrierung und die Pull-Anmeldedaten dynamisch zu überschreiben. Diese Bemühungen müssen zwischen demjenigen, der die Arbeitslast bereitstellt, und demjenigen, der sie einsetzt, koordiniert werden. Weitere Informationen finden Sie unter Dynamische Registry-Referenz verwenden.

Führen Sie die folgenden Schritte aus, um die Base64 verschlüsselte Archivdatei. Der Base64 Die Ausgabe erfolgt im compose.b64 Datei. Wechseln Sie in das Verzeichnis <COMPOSE_Folder> und führen Sie die folgenden Befehle aus:

tar czvf compose.tgz docker-compose.yml

base64 -w0 compose.tgz > compose.b64

Stellen Sie sicher, dass die erstellte TGZ-Datei nur Verzeichnisse und normale Dateien enthält. Links oder Pipes werden nicht unterstützt.

Kopieren Sie den Inhalt von compose.b64 als Wert von 'compose-> archive'.

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

Für das hier aufgeführte Beispiel wird eine Ausgabe wie die folgende zurückgegeben:

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

Unterabschnitt play

Im play Im Unterabschnitt können Sie die Arbeitslast definieren durch Pod-Deskriptoren. Jeder Pod kann eine oder mehrere Containerdefinitionen enthalten. Beschreibungen können auf eine der folgenden Weisen bereitgestellt werden:

• Im einfachen YAML-Format im Unterabschnitt resources von play. Dieser Abschnitt ist ein Array von Deskriptoren und unterstützt zwei Deskriptortypen: Pods und ConfigMaps.

  Das folgende Beispiel veranschaulicht, wie der Abschnitt resources verwendet wird:

  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
  

  Das folgende Beispiel veranschaulicht die Verwendung von initcontainers mit dem Abschnitt resources:

  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
  

• Im archive Unterabschnitt von play, das Archiv ist ein Base64 codierte, gzippte TAR-Datei. Die Pods oder ConfigMaps werden als YAML-Dateien auf der höchsten Ebene in dieser TAR-Datei dargestellt. Die Datei kann auch zusätzliche Dateien enthalten und alle Dateien werden in das Host-Dateisystem extrahiert, bevor die Pods gestartet werden. Das aktuelle Arbeitsverzeichnis ist das Verzeichnis, in das die Dateien extrahiert wurden, sodass es möglich ist, einen Datenträgermount mit einem relativen Pfad zu verwenden, um die Dateien oder Verzeichnisse aus der YAML-Datei anzuhängen.

  Beispiel:

  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
  

• In einem Vorlagenformat im Unterabschnitt templates von play. Dieser Abschnitt ist ein Array von Deskriptoren im YAML-Format. Pods oder ConfigMaps können variable Punkte (POV) aufweisen, die zum Zeitpunkt der Erstellung der Deskriptoren nicht bekannt sind. Diese POVs können als Vorlagen dargestellt werden und die Werte werden zum Zeitpunkt der Bereitstellung aus den Informationen im Vertrag vervollständigt. Wir verwenden Go-Vorlagen als Vorlagensyntax, die mit der für Helm-Diagrammeidentisch ist, sodass Vorlagen problemlos mit k8sausgetauscht werden können. Die folgenden Built-In-Objekte werden unterstützt:

  • Umgebung: Dieses Objekt enthält die Umgebungsvariablen, die zwischen der Workload und dem Umgebungsabschnitt zusammengeführt wurden. Das Objekt ist als {{ .Env }} verfügbar.

  Beispiel:

  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
  

  Der Ausdruck {{ .Env REGISTRY }} referenziert die Umgebungsvariable REGISTRY, die in diesem Beispiel im Abschnitt env des Vertrags definiert ist.

  Die Vorlagen müssen gültig YAMLsein, daher muss ein Ersetzungsausdruck mit Escapezeichen versehen werden, wenn er als erster Teil einer Zeichenfolge angezeigt wird. Andernfalls kollidiert es mit dem Blockzuordnung Syntax. Dies unterscheidet sich von Helm-Vorlagen, bei denen Ausdrücke auf die Textdarstellung des Dokuments und nicht auf die Modelldarstellung angewendet werden.

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

Unterabschnitt images

Docker hat das Ausscheiden von Docker Content Trust (DCT ) bekannt gegeben. Da DCT auf dem veralteten Notary v1 Framework aufbaut, das nicht mehr aktiv gepflegt wird, wird es nicht als zukunftsfähige oder nachhaltige Lösung für die Bildsignierung und -verifizierung angesehen. Daher werden die Kunden ermutigt, von DCT abzurücken und OCI-konforme Bildsignier- und Verifizierungstechnologien zu verwenden, die mit den aktuellen Sicherheitsstandards für die Lieferkette übereinstimmen. Sie können Container-Images auf IBM Cloud Container Registry (ICR) migrieren. ICR ist in den Red Hat Signing Service (RHS ) als vertrauenswürdige Signierquelle integriert und bietet ein herstellergestütztes Vertrauensmodell sowie eine Anpassung an die aktuellen Best Practices für Containersicherheit und Lieferketten. Weitere Informationen finden Sie unter Ausscheiden von Docker Content Trust.

Der Unterabschnitt images ist nur für ein signiertes Image gedacht.

<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

Der Unterabschnitt workload- volumes

Der Abschnitt volumes muss im Vertrag nur angegeben werden, wenn zum Zeitpunkt der Erstellung ein Datenvolumen an die Instanz angehängt wird. Die in diesem Abschnitt bereitgestellten Informationen werden verwendet, um das angehängte Datenvolumen (vom Benutzer bereitgestellt) zu mounten, und werden später mithilfe der in den Abschnitten " workload " und " env " bereitgestellten "Seeds" verschlüsselt. Sie können einen beliebigen Pfad für das Feld "mount" angeben. Der vom Benutzer bereitgestellte Pfad wird intern zum Mounten des Datenvolumens verwendet. Der im Vertrag angegebene Mount-Pfad muss mit dem Pfad übereinstimmen, der im Abschnitt "Volumes" der docker-compose.yaml-Datei angegeben ist, damit alle Daten, die mit der Container-Arbeitslast verbunden sind, in diesem Datenvolumen gespeichert werden.

Der Unterabschnitt volumes unterstützt die automatische Verschlüsselung des Datenvolumens mit vom Benutzer bereitgestellten Seedwerten. Wenn ein Datenträger an die Hyper Protect Virtual Servers-Instanz angehängt ist, wird er automatisch mit den Seedwerten verschlüsselt, die über das Feld "seed" in den volumes-Unterabschnitten des Vertrags bereitgestellt werden. Daher müssen zwei Seedwerte bereitgestellt werden, einer über den Abschnitt workload (durch die Workloadpersona) und der andere über den Abschnitt env (durch die Bereitstellerpersona). Diese beiden Seedwerte werden intern in UTF8-Sequenzen konvertiert und anschließend verkettet. Später wird der Hash (SHA256) der verketteten Sequenz als Hexdigest berechnet, der als LUKS-Kennphrase zum Verschlüsseln des Datenträgers verwendet wird.

Derzeit müssen die Seeds env und workload eine Mindestlänge von 3 Zeichen aufweisen. Ab März 2026 wird dieses Minimum auf 15 Zeichen erhöht. Alle Seed-Werte, die kürzer als 15 Zeichen sind, können nach März 2026 zu Fehlern oder fehlgeschlagenen Bereitstellungen führen. Um Störungen zu vermeiden, aktualisieren Sie alle Seed-Werte so bald wie möglich auf eine Länge von mindestens 15 Zeichen. Die Regeln werden im folgenden Abschnitt definiert.

Ab März 2026 müssen Sie diese Regeln befolgen, um Saatgut zu erzeugen:

• Keine Leerzeichen erlaubt.
• Muss mindestens 15 Zeichen enthalten. Nachfolgend sind die zulässigen Zeichen aufgeführt:
  • Kleinbuchstaben (a-z)
  • Großbuchstaben (A-Z)
  • Zahlen (0-9)
  • Sonderzeichen !@#$%^&*(),.?":{}|<>_-

Mit dem folgenden Befehl können Sie den Hexdigest überprüfen:

echo -n "seed1seed2" | sha256sum

Hier erfahren Sie, wie der "Seed" im Workloadabschnitt des Vertrags bereitgestellt werden kann. Weitere Informationen dazu, wie die Eingabe "Seed" über den Abschnitt env bereitgestellt wird, enthält der Abschnitt env. Es ist obligatorisch, beide Seeds für die Verschlüsselung bereitzustellen. Die Verschlüsselung schlägt fehl, wenn nur einer der Seeds bereitgestellt wird und die Instanz beendet wird.

Durch die Integration mit können Sie Ihren gespeicherten Daten ein höheres Hyper Protect Crypto Services Maß an Verschlüsselungsschutz und -kontrolle hinzufügen. Beginnend mit können Sie ibm-hyper-protect-container-runtime-1-0-s390x-11 verwenden, Hyper Protect Crypto Services um einen Zufallswert als dritten Startwert zu generieren und diesen mit Ihrem Root-Schlüssel zu verpacken. Die LUKS-Kennphrase wird mit drei Seedwerten generiert-dem Seedwert in der Metadatenpartition und den beiden Seedwerten aus dem Vertrag. Weitere Informationen finden Sie im Abschnitt Eigene Daten schützen.

Das folgende Snippet ist ein Beispiel für den Datenträgerabschnitt:

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

Beginnend mit der HPCR-Image-Version wird bei Hyper Protect Virtual Servers neuen VPC-Instanzen das ibm-hyper-protect-container-runtime-1-0-s390x-9 Datenvolumen in zwei Teile partitioniert. Die erste Partition ( 100Mib ) ist für interne Metadaten reserviert; die zweite Partition bleibt als Datenvolumen für die Arbeitslast erhalten. Es werden nur neue Datenträger partitioniert und Sie können den partitionierten Datenträger nicht mit einer älteren Version des HPCR-Image verwenden. Die Bereitstellung mit einem vorhandenen verschlüsselten Datenträger funktioniert ebenfalls. Der Unterschied besteht darin, dass der vorhandene Datenträger nicht partitioniert wird und Sie auch zu einem älteren Image mit diesem Datenträger zurückkehren können.

Ab ibm-hyper-protect-container-runtime-1-0-s390x-12 können der Bereitsteller und der Provider das Feature "Rolling of Seeds" verwenden. Es wird eine Option bereitgestellt, um die Samen zu rollen oder zu rotieren, um die Sicherheitslage zu erhöhen, oder wenn der Samen beeinträchtigt wird. Wenn der Bereitsteller und/oder der Provider die Seedwerte übertragen möchten, müssen die aktuellen Seedinformationen im Parameter previousSeed und die neuen Seedinformationen im Parameter seed angegeben werden.

Das folgende Snippet ist ein Beispiel für den Datenträgerabschnitt:

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

Ab ibm-hyper-protect-container-runtime-1-0-s390x-13 können Sie mehrere Datenträger zuordnen, wenn Sie die virtuelle Serverinstanz starten. Volumes, die angehängt werden, während die Instanz ausgeführt wird, werden ignoriert.

Das folgende Snippet ist ein Beispiel für den Datenträgerabschnitt:

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"

Unterabschnitt 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)

Der Unterabschnitt env- volumes

Lesen Sie den Unterabschnitt workload-volumes des Workloadabschnitts, bevor Sie mit diesem Abschnitt fortfahren. Wie bereits erwähnt, müssen Sie für die automatische Plattenverschlüsselung des angehängten Datenträgers zwei Seedwerte für Kunden bereitstellen, einen im Unterabschnitt workload- volumes und einen im Unterabschnitt env- volumes. Die Samen können ein beliebiger Zufallstext Ihrer Wahl sein.

Sehen Sie sich das folgende Beispiel für den Unterabschnitt env- volumes an:

volumes:
  test:
    seed: "seed_value_with_minimum_15_characters"

Wenn Sie die Funktion "rolling of seeds" verwenden, können Sie das folgende Snippet als Beispiel verwenden:

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

Wenn Sie mehrere Datenträger verwenden, muss der Implementierer sicherstellen, dass die Datenträger im Voraus erstellt werden, und die Datenträger-ID in der Vertragsdatei angeben. Andernfalls muss der Datenträgername angegeben und der Datenträger mit demselben Namen erstellt werden. Wenn beide nicht angegeben sind, wird der Volume-Schlüssel als Volume-Name betrachtet und das Volume muss mit demselben Namen erstellt werden, während oder bevor die virtuelle Serverinstanz erstellt wird. Der folgende Ausschnitt dient als Beispiel:

 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"

Dabei gilt:

• Volumenname: Dies ist der Name, den Sie beim Erstellen des Volumes in der VPC angegeben haben.
• Datenträger-ID: Die vom System generierte Datenträger-ID des erstellten Datenträgers.
• Datenträgerschlüssel: Der eindeutige Datenträgername für jeden Datenträger.

Der Datenträger-Schlüssel muss mit dem Schlüssel im Unter abschnitt "Datenträger-Arbeitslast" übereinstimmen.

Wie bereits erwähnt, können Sie eine Integration mit Hyper Protect Crypto Services durchführen, um einen dritten Seed zu generieren und ihn mit Ihrem Rootschlüssel einzuschließen. Beispiel: Weitere Informationen finden Sie im Abschnitt Eigene Daten schützen.

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

Unterabschnitt signingKey

Weitere Informationen zur Verwendung der signingKey finden Sie unter Vertragssignatur.

Unterabschnitt env

• Wenn Pod-Deskriptoren im Abschnitt workload verwendet werden:

  Ein Beispiel für das Vorlagenformat finden Sie im Unterabschnitt play.

• Wenn eine Docker Compose-Datei im Abschnitt workload verwendet wird:

  Wenn die Docker Compose-Datei einen Umgebungsabschnitt enthält, können Sie das folgende Snippet als Beispiel verwenden:

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

  Wenn die docker-compose-Datei einen Umgebungsabschnitt enthält, wie im vorherigen Beispiel gezeigt, können Sie die Werte im Abschnitt env des Deployers übergeben. Das folgende Beispiel zeigt, wie die Werte für die Variablen env angegeben werden:

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

Verschlüsselungszertifikat herunterladen und öffentlichen Schlüssel extrahieren

1. Laden Sie das Zertifikat herunter. In der folgenden Tabelle sind die Ablaufdaten der Verschlüsselungszertifikate sowie die Daten, an denen die Images als veraltet gelten, je nach Version des Images aufgeführt.

Hinweis

• Veraltet- Sie können das Image verwenden, um eine Instanz über die IBM Cloud CLI zu erstellen. Der Status "veraltet" kann von der Verwendung des Bildes abhalten, bevor der Status auf "veraltet" geändert wird. Der Image-Katalog enthält immer die beiden neuesten Image-Versionen: n und n-1. Wenn eine neue Version ( n+1 ) verfügbar ist, wird die älteste Version ( n-1 ) vom System veraltet.
• Veraltet: Nachdem das mit dem Image verknüpfte Zertifikat abgelaufen ist, ist das Image nicht mehr für die Bereitstellung einer Instanz verfügbar.
• Laden Sie immer die Verschlüsselungszertifikate herunter, die dem Bild entsprechen, und verschlüsseln Sie die Verträge.

Sie können auch den Befehl IBM Cloud image list verwenden, um den Status der veralteten oder veralteten Images zu überprüfen.

Informationen zum Abrufen des Status des Image finden Sie in der Dokumentation zum Befehl 'image list'.

2. Validieren Sie das Verschlüsselungszertifikat, indem Sie den Anweisungen im Thema "Validierung des Vertragsverschlüsselungszertifikats " folgen.

Verschlüsselten Abschnitt workload eines Vertrags erstellen

Der Wert eines Abschnitts in einem Vertrag kann einfacher Text oder verschlüsselt sein. Führen Sie die folgenden Schritte auf einem Ubuntu-System aus, um den in einem Vertrag verwendeten Abschnitt "Arbeitslast" zu verschlüsseln:

1. Erstellen Sie die Datei docker-compose.yaml auf der Basis Ihrer Workloadanforderungen. Beispiel:

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

   Weitere Informationen finden Sie unter Übersicht über Docker Compose.

2. Erstellen Sie den Workloadabschnitt des Vertrags und fügen Sie den Inhalt in der Datei workload.yaml hinzu.

   Im Folgenden finden Sie ein Beispiel ​workload.yaml für:

   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. Exportieren Sie den vollständigen Pfad der Datei workload.yaml und 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. Verwenden Sie den folgenden Befehl, um ein zufälliges Passwort zu erstellen. Der Vertrag wird durch symmetrisches AES mit einem zufälligen Passwort verschlüsselt.

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

5. Beginnend mit OpenSSL 3.0 ist der Unterbefehl OpenSSL rsautl veraltet und wird durch den Unterbefehl pkeyutl ersetzt. Verwenden Sie einen der folgenden Befehle, um das Passwort mit ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt zu verschlüsseln:

   • Verwendung von rsautl (veraltet):

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

   • Verwendung von pkeyutl (empfohlen):

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

6. Verwenden Sie den folgenden Befehl, um die Datei workload.yaml mit einem automatisch generierten Kennwort zu verschlüsseln:

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

7. Verwenden Sie den folgenden Befehl, um den verschlüsselten Abschnitt des Vertrags abzurufen:

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

8. Rufen Sie die Ausgabe aus Schritt 7 ab und fügen Sie sie zur Datei user-data.yaml hinzu.

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

   Das Präfix hyper-protect-basic ist obligatorisch.

Verschlüsselten Abschnitt env eines Vertrags erstellen

Führen Sie die folgenden Schritte auf einem Ubuntu-System aus, um den in einem Vertrag verwendeten env-Abschnitt zu verschlüsseln:

1. Erstellen Sie den env-Abschnitt des Vertrags und fügen Sie den Inhalt in der Datei env.yaml hinzu.

   Im Folgenden finden Sie ein Beispiel für 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. Exportieren Sie den vollständigen Pfad der Datei env.yaml und 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. Verwenden Sie den folgenden Befehl, um ein zufälliges Passwort zu erstellen:

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

4. Beginnend mit OpenSSL 3.0 ist der Unterbefehl OpenSSL rsautl veraltet und wird durch den Unterbefehl pkeyutl ersetzt. Verwenden Sie einen der folgenden Befehle, um das Passwort mit ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt zu verschlüsseln:

   • rsautl (veraltet):

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

   • pkeyutl (empfohlen):

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

5. Verwenden Sie den folgenden Befehl, um env.yaml mit einem automatisch generierten Kennwort zu verschlüsseln:

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

6. Verwenden Sie den folgenden Befehl, um den verschlüsselten Abschnitt des Vertrags abzurufen:

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

7. Informationen zum Verschlüsseln des Workloadabschnitts finden Sie unter Verschlüsselten workload-Abschnitt eines Vertrags erstellen.

8. Rufen Sie die Ausgabe von Schritt 6 ab und fügen Sie sie zur Datei user-data.yaml hinzu.

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

Warnprotokolle zum Ablauf von Verschlüsselungs- und Bescheinigungszertifikaten

HPVS protokolliert Warnmeldungen über anstehende und abgelaufene Verschlüsselungs- und Bescheinigungszertifikate an den konfigurierten Protokollierungsdienst.

Nachstehend finden Sie den Zeitplan für die Notifizierung:

• 30 Tage vor Ablauf der Gültigkeit: Alle 24 Stunden wird eine Warnmeldung erzeugt, die darauf hinweist, dass das Zertifikat in einem Monat abläuft.

  Beispiel:

  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 Tage vor Ablauf der Gültigkeit: Alle 12 Stunden, wenn das Verfallsdatum näher rückt, werden Warnmeldungen protokolliert, die darauf hinweisen, dass Maßnahmen ergriffen werden müssen.

  Beispiel:

  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!!!
  

• Nach Ablauf des Zertifikats: Wenn das Zertifikat abgelaufen ist, gibt HPVS alle 4 Stunden Warnmeldungen aus, bis das HPVS-Image aktualisiert wird.

  Beispiel:

  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. Details Ihrer Protokollierungsinstanz abrufen

Sie können die Protokollierung mit IBM Log Analysis oder einem generischen Syslog-Back-End konfigurieren. In diesem Beispiel wird IBM Log Analysisverwendet. Sie können aus verschiedenen Plänen wählen. Um zu verstehen, wie Sie die erforderlichen Details wie den Hostnamen und den Aufnahmeschlüssel erhalten, siehe Protokollierung für Hyper Protect Virtual Servers für VPC.

2. Abschnitt env erstellen

Achten Sie darauf, dass Sie das Pipe-Symbol '|' nicht vergessen, wenn Sie einen Vertrag mit einfachem Text verwenden. Es ist nicht erforderlich, wenn Sie den Abschnitt verschlüsseln möchten.

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

3. Vorbereiten der Datei 'docker-compose'

Wenn Sie über die Protokollierungsdetails verfügen, suchen Sie nach einer einfachen Docker Compose-Datei. Das folgende Beispiel hat einen öffentlichen NGINX Container. Erstellen Sie eine docker-compose.yaml anhand des Beispiels.

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

4. base64-encoded Version der Docker Compose-Datei abrufen

tar -czvf compose.tgz docker-compose.yaml

base64 -i compose.tgz > compose.b64

5. Erstellen Sie den Abschnitt "Erstellen" damit

  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. Workloadabschnitt füllen

Achten Sie darauf, dass Sie das Pipe-Symbol (|) nicht übersehen, wenn Sie einen Vertrag mit einfachem Text verwenden.

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. Ihr einfacher Vertrag ist bereit

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==