La sous-section auths

La section auths contient des informations sur le registre du conteneur. Si une image publique est utilisée dans le contrat, vous n'avez pas besoin de la section auths car aucune donnée d'identification n'est requise. La sous-section auths est requise uniquement si les images de conteneur sont privées. Cette sous-section ne contient pas d'informations d'image, comme illustré dans l'exemple suivant. Cette sous-section doit contenir le nom du registre d'images et les données d'identification telles que username-password pour le même. La clé doit être le nom d'hôte du Container Registry ou la chaîne suivante pour le registre Docker par défaut :

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

Le fragment suivant illustre un exemple pour IBM Cloud Registry. Pour plus d'informations sur l'utilisation de la clé d'API, voir Utilisation du logiciel client pour l'authentification dans l'automatisation.

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

La sous-section compose

Il se compose d'une sous-section d'archivage. La sous-section d'archive contient l'archive de fichier TGZ codée en Base64 du fichier docker-compose.yaml. Etant donné que l'image Hyper Protect Container Runtime utilise Docker Engine et Docker Compose pour démarrer le conteneur, les informations sur le conteneur doivent d'abord être créées à l'aide d'un fichier docker-compose standard. Ce fichier est ensuite archivé et encodé en format Base64, et le résultat de ce processus est fourni comme valeur à la sous-section archive, dans la section de composition. Pour plus d'informations, voir Présentation de Docker Compose.

Les points de montage spécifiés sous les informations de volumes du fichier docker-compose peuvent être alignés avec le point de montage de volume spécifié dans la section de charge de travail du contrat.

L'exécution d'une génération dans le cadre d'un fichier Docker Compose n'est pas prise en charge. Assurez-vous que votre fichier Docker Compose ne comporte pas de section build.

Les formats "yaml" et "yml" sont pris en charge pour le fichier docker-compose. Consultez l'exemple suivant de fichier Docker Compose.

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

Il existe des cas d'utilisation où le registre n'est pas connu lorsque la section de la charge de travail est pré-chiffrée. Par exemple, lorsque le fournisseur de charge de travail souhaite autoriser le déployeur à utiliser un miroir de registre ou un registre privé Container Registry, il est possible de remplacer dynamiquement le registre et les informations d'identification de récupération. Cet effort doit être coordonné entre le fournisseur de la charge de travail et le responsable du déploiement. Pour plus d'informations, voir Utilisation d'une référence de registre dynamique.

Effectuez les étapes suivantes pour obtenir le Base64 fichier d'archive codé. Le Base64 la sortie est disponible dans le compose.b64 déposer. Accédez à <COMPOSE_Folder> et exécutez les commandes suivantes:

tar czvf compose.tgz docker-compose.yml

base64 -w0 compose.tgz > compose.b64

Assurez-vous que le fichier compose tgz contient uniquement des répertoires et des fichiers normaux. Les liens ou les canaux de communication ne sont pas pris en charge.

Copiez le contenu de compose.b64 en tant que valeur de compose-> archive.

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

Pour cet exemple, vous obtenez une réponse similaire à la sortie suivante :

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

La sous-section play

Dans le play sous-section, vous pouvez définir la charge de travail via Descripteurs de pods. Chaque pod peut contenir une ou plusieurs définitions de conteneur. Les descripteurs peuvent être fournis de l'une des manières suivantes :

• Au format YAML simple dans la sous-section resources de play. Cette section est un tableau de descripteurs et prend en charge deux types de descripteurs: Pods et ConfigMaps.

  L'exemple suivant montre comment utiliser la section 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
  

  L'exemple suivant illustre comment utiliser la section initcontainers avec la section 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
  

• Dans le archive sous-section de play, les archives sont un Base64 fichier tar codé et compressé. Les pods ou ConfigMaps sont représentés sous forme de fichiers YAML, au niveau supérieur dans ce fichier tar. Le fichier peut également contenir des fichiers supplémentaires et tous les fichiers sont extraits vers le système de fichiers hôte avant le démarrage des Pods. Le répertoire de travail en cours est le répertoire dans lequel les fichiers ont été extraits. Il est donc possible d'utiliser un montage de volume avec un chemin relatif pour monter les fichiers ou les répertoires à partir du fichier YAML.

  Exemple :

  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
  

• Dans un format de modèle dans la sous-section templates de play. Cette section est un tableau de descripteurs au format YAML. Les pods ou ConfigMaps peuvent avoir des points de variabilité (POV) qui ne sont pas connus au moment de la rédaction des descripteurs. Ces POV peuvent être représentés sous forme de modèles et les valeurs sont complétées au moment du déploiement à partir des informations contenues dans le contrat. Nous utilisons des modèles go comme syntaxe de modélisation, qui est la même que celle utilisée pour les chartes Helm, de sorte que les modèles peuvent facilement être échangés avec k8s. Nous prenons en charge les objets Built-In suivants:

  • Environnement: cet objet contient les variables d'environnement fusionnées entre la charge de travail et la section d'environnement. L'objet est disponible sous la forme {{ .Env }}.

  Exemple :

  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
  

  L'expression {{ .Env REGISTRY }} fait référence à la variable d'environnement REGISTRY qui, dans cet exemple, est définie dans la section env du contrat.

  Les modèles doivent être valides YAML, de sorte qu'une expression de remplacement doit être mise en échappement si elle apparaît en tant que première partie d'une chaîne. Sinon, il entre en collision avec le mappage de blocs syntaxe. Ceci est différent des modèles de barre où les expressions sont appliquées à la représentation textuelle du document au lieu de la représentation du modèle.

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

La sous-section images

Docker a annoncé le départ à la retraite de Docker Content Trust (DCT). Étant donné que DCT repose sur l'ancien cadre Notary v1, qui n'est plus activement maintenu, il n'est pas considéré comme une solution prête pour l'avenir ou durable pour la signature et la vérification d'images. Par conséquent, les clients sont encouragés à abandonner le DCT et à adopter des technologies de signature et de vérification d'images conformes à l'OCI qui s'alignent sur les normes actuelles de sécurité de la chaîne d'approvisionnement. Vous pouvez migrer des images de conteneurs vers IBM Cloud Container Registry (ICR). ICR s'intègre au service de signature Red Hat (RHS) en tant que racine de confiance de la signature, fournissant un modèle de confiance soutenu par le fournisseur et s'alignant sur les meilleures pratiques contemporaines en matière de sécurité des conteneurs et de chaîne d'approvisionnement. Pour plus d'informations, voir Retirons Docker Content Trust.

La sous-section images est destinée uniquement à une image signée.

<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

La sous-section workload- volumes

La section volumes doit être fournie dans le contrat uniquement si un volume de données est connecté à l'instance au moment de la création. Les informations fournies dans cette section sont utilisées pour monter le volume de données joint (fourni par l'utilisateur) et sont ensuite chiffrées à l'aide des « clés » fournies dans les sections workload et env. Vous pouvez indiquer le chemin de votre choix pour la zone "mount". Le chemin fourni par l'utilisateur est utilisé en interne pour monter le volume de données. Le chemin de montage fourni dans le contrat doit correspondre au chemin fourni dans la section volumes du fichier d' docker-compose.yaml, afin que toutes les données associées à la charge de travail du conteneur soient stockées dans ce volume de données.

La sous-section volumes prend en charge le chiffrement automatique du volume de données avec des valeurs de départ fournies par l'utilisateur. Si un volume de données est connecté à l'instance Hyper Protect Virtual Servers, il est chiffré automatiquement avec les valeurs de départ fournies via la zone "seed" dans les sous-sections volumes du contrat. Par conséquent, deux valeurs de départ doivent être fournies, l'une via la section workload (par la personne de charge de travail) et l'autre via la section env (par la personne de déployeur). Ces deux valeurs de départ sont converties en interne en séquences UTF8, puis concaténées. Par la suite, le hachage (SHA256) de la séquence concaténée est calculé comme un hexdigest, qui est utilisé comme phrase passe LUKS pour chiffrer le volume de données.

Actuellement, les semences env et workload requièrent une longueur minimale de 3 caractères. À partir de mars 2026, ce minimum sera porté à 15 caractères. Toute valeur de semence inférieure à 15 caractères après mars 2026 peut entraîner des erreurs ou des échecs de déploiement. Pour éviter les perturbations, mettez à jour dès que possible toutes les valeurs de semences avec une longueur d'au moins 15 caractères. Les règles sont définies dans la section suivante.

À partir de mars 2026, vous devrez respecter les règles suivantes pour créer des semences :

• Aucun espace autorisé.
• Doit comporter au moins 15 caractères. Les caractères autorisés sont les suivants :
  • Lettres minuscules (a-z)
  • Lettres majuscules (A-Z)
  • Nombres (0-9)
  • Caractères spéciaux !@#$%^&*(),.?":{}|<>_-

Vous pouvez utiliser la commande suivante pour valider l'hexdigest :

echo -n "seed1seed2" | sha256sum

Ici, vous pouvez apprendre comment la "valeur de départ" peut être fournie dans la section de la charge de travail du contrat. Pour plus d'informations sur la façon dont l'entrée "seed" peut être fournie via la section env, voir La section env. Il est obligatoire de fournir les deux valeurs de départ pour le chiffrement. Le chiffrement échoue si une seule des valeurs de départ est fournie et que l'instance est arrêtée.

Vous pouvez ajouter un niveau supérieur de protection et de contrôle par chiffrement à vos données au repos en intégrant Hyper Protect Crypto Services. À partir de ibm-hyper-protect-container-runtime-1-0-s390x-11, vous pouvez utiliser Hyper Protect Crypto Services pour générer une valeur aléatoire comme troisième graine et l'envelopper avec votre clé racine. La phrase passe LUKS est générée à l'aide de trois valeurs de départ: la valeur de départ dans la partition de métadonnées et les deux valeurs de départ du contrat. Pour plus d'informations, voir Sécurisation de vos données.

Le fragment suivant est un exemple pour la section volumes:

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

À partir de la version d'image ibm-hyper-protect-container-runtime-1-0-s390x-9 HPCR, pour les Hyper Protect Virtual Servers nouvelles instances VPC, le volume de données est partitionné en deux parties. La première partition ( 100Mib ) est réservée aux métadonnées internes; la deuxième partition reste le volume de données pour la charge de travail. Seuls les nouveaux volumes sont partitionnés et vous ne pouvez pas utiliser le volume partitionné avec une version antérieure de l'image HPCR. La mise à disposition avec un volume chiffré existant fonctionne également. La différence est que le volume existant n'est pas partitionné et que vous pouvez également revenir à une image plus ancienne avec ce volume.

A partir de ibm-hyper-protect-container-runtime-1-0-s390x-12, le déployeur et le fournisseur peuvent utiliser la fonction "rolling of seeds". Une option est fournie pour rouler ou faire pivoter les points de départ afin d'augmenter la posture de sécurité, ou si la valeur de départ est compromise. Lorsque le déployeur ou le fournisseur ou les deux souhaitent transférer les valeurs de départ, les informations de valeur de départ en cours doivent être spécifiées dans le paramètre previousSeed et les nouvelles informations de valeur de départ doivent être spécifiées dans le paramètre seed.

Le fragment suivant est un exemple pour la section volumes:

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

A partir de la ibm-hyper-protect-container-runtime-1-0-s390x-13, vous pouvez connecter plusieurs volumes lorsque vous démarrez l'instance de serveur virtuel. Les volumes qui sont attachés lorsque l'instance est en cours d'exécution sont ignorés.

Le fragment suivant est un exemple pour la section 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"

La sous-section 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)

La sous-section env- volumes

Lisez la sous-section workload-volumes de la section workload avant de passer à cette section. Comme indiqué précédemment, pour le chiffrement de disque automatique du volume de données connecté, vous devez fournir deux valeurs de départ client, l'une dans la sous-section workload- volumes et l'autre dans la sous-section env- volumes. Les graines peuvent être n'importe quel texte aléatoire de votre choix.

Voir l'exemple suivant de la sous-section env- volumes:

volumes:
  test:
    seed: "seed_value_with_minimum_15_characters"

Lorsque vous utilisez la fonction "rolling of seeds", vous pouvez utiliser le fragment suivant comme exemple:

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

Lorsque vous utilisez plusieurs volumes, le déployeur doit s'assurer que les volumes sont créés à l'avance et spécifier également l'ID de volume dans le fichier de contrat. Sinon, le nom de volume doit être indiqué et le volume doit être créé avec le même nom. Si les deux ne sont pas spécifiés, la clé de volume est considérée comme le nom du volume et le volume doit être créé avec le même nom pendant ou avant la création de l'instance de serveur virtuel. Voici un exemple d'extrait :

 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"

Où :

• Nom du volume : il s'agit du nom que vous avez spécifié lors de la création du volume sur le VPC.
• ID volume: ID volume généré par le système du volume créé.
• Clé de volume: nom unique de chaque volume.

La clé de volume doit être la même que celle de la sous-section workload - volumes.

Comme indiqué, vous pouvez effectuer une intégration à Hyper Protect Crypto Services pour générer une troisième valeur de départ et l'encapsuler avec votre clé racine. Consultez l'exemple suivant. Pour plus d'informations, voir Sécurisation de vos données.

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

Sous-section signingKey

Pour plus d'informations sur l'utilisation de signingKey, voir Signature du contrat.

Sous-section env

• Si des descripteurs de pod sont utilisés dans la section workload:

  Voir l'exemple de format de modèle dans la sous-section play.

• Si un fichier Docker Compose est utilisé dans la section workload:

  Si le fichier docker compose comporte une section d'environnement, vous pouvez utiliser le fragment suivant comme exemple:

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

  Lorsque le fichier compose du docker comporte une section environment, comme dans l'exemple précédent, vous pouvez transmettre les valeurs dans la section env du deployer. L'exemple suivant montre comment spécifier les valeurs des variables env:

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

Téléchargement du certificat de chiffrement et extraction de la clé publique

1. Téléchargez le certificat. Le tableau ci-dessous répertorie les dates d'expiration des certificats de chiffrement ainsi que les dates de fin de prise en charge ou d'obsolescence des images, en fonction de la version de l'image.

Remarque

• Déclassé- Vous pouvez utiliser l'image pour créer une instance à partir de la CLI de IBM Cloud. Le statut "déprécié" peut décourager l'utilisation de l'image avant que son statut ne devienne "obsolète". Le catalogue d'images conserve toujours les deux versions d'images les plus récentes : n et n-1. Lorsqu'une nouvelle version ( n+1 ) est disponible, le système supprime la version la plus ancienne ( n-1 ).
• Obsolète: Lorsque le certificat associé à l'image expire, l'image n'est plus disponible pour provisionner une instance.
• Téléchargez toujours les certificats de cryptage correspondant à l'image et cryptez les contrats.

Pour vérifier le statut d'obsolescence ou d'obsolescence de l'image, vous pouvez également utiliser la commande de liste d'images IBM Cloud.

Vous pouvez vous référer à la documentation pour la commande de liste d'images afin d'obtenir le statut de l'image.

2. Valider le certificat de chiffrement en suivant les instructions de la rubrique Validation du certificat de chiffrement du contrat.

Création de la section workload chiffrée d'un contrat

La valeur de n'importe quelle section d'un contrat peut être en texte clair ou chiffrée. Effectuez les étapes suivantes sur un système d' Ubuntu s pour chiffrer la section de la charge de travail utilisée dans un contrat :

1. Créez le fichier docker-compose.yaml en fonction de vos besoins en charge de travail. Par exemple :

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

   Pour plus d'informations, voir Présentation de Docker Compose.

2. Créez la section de charge de travail du contrat et ajoutez le contenu dans le fichier workload.yaml.

   Voici un exemple de ​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. Exportez le chemin complet du fichier workload.yaml et de 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. Utilisez la commande suivante pour créer un mot de passe aléatoire. Le contrat est crypté au moyen d'un algorithme symétrique AES et d'un mot de passe aléatoire.

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

5. À partir de OpenSSL 3.0, la sous-commande OpenSSL rsautl est obsolète et remplacée par la sous-commande pkeyutl. Utilisez l'une des commandes suivantes pour crypter le mot de passe avec ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt:

   • Utilisation de rsautl (obsolète):

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

   • Utilisation de pkeyutl (recommandé):

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

6. Utilisez la commande suivante pour chiffrer le fichier workload.yaml avec un mot de passe aléatoire:

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

7. Utilisez la commande suivante pour obtenir la section chiffrée du contrat:

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

8. Obtenez la sortie de l'étape 7 et ajoutez-la au fichier user-data.yaml.

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

   Le préfixe hyper-protect-basic est obligatoire.

Création de la section env chiffrée d'un contrat

Effectuez les étapes suivantes sur un système d' Ubuntu s pour chiffrer la section d' env s utilisée dans un contrat :

1. Créez la section env du contrat et ajoutez le contenu dans le fichier env.yaml.

   Voici un exemple de 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. Exportez le chemin complet du fichier env.yaml et de 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. Utilisez la commande suivante pour créer un mot de passe aléatoire :

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

4. À partir de OpenSSL 3.0, la sous-commande OpenSSL rsautl est obsolète et remplacée par la sous-commande pkeyutl. Utilisez l'une des commandes suivantes pour crypter le mot de passe avec ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt:

   • rsautl (obsolète):

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

   • pkeyutl (recommandé):

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

5. Utilisez la commande suivante pour chiffrer env.yaml avec un mot de passe aléatoire:

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

6. Utilisez la commande suivante pour obtenir la section chiffrée du contrat:

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

7. Pour chiffrer la section de charge de travail, voir Création de la section workload chiffrée d'un contrat.

8. Obtenez la sortie de l'étape 6 et ajoutez-la au fichier user-data.yaml.

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

Journaux d'avertissement d'expiration des certificats de chiffrement et d'attestation

HPVS envoie des messages d'avertissement au service de journalisation configuré concernant les certificats de chiffrement et d'attestation à venir et expirés.

Le calendrier de notification est le suivant :

• 30 jours avant l'expiration: Un message d'avertissement est généré toutes les 24 heures, notifiant que le certificat expirera dans un mois.

  Exemple :

  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 jours avant l'expiration: Des messages d'avertissement sont enregistrés toutes les 12 heures à l'approche de la date d'expiration, soulignant la nécessité d'agir.

  Exemple :

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

• Après l'expiration du certificat: Si le certificat a expiré, HPVS enregistre des messages d'avertissement toutes les 4 heures jusqu'à ce que l'image HPVS soit mise à jour.

  Exemple :

  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. Obtenez les détails de votre instance de journalisation

Vous pouvez configurer la journalisation avec IBM Log Analysis ou un système de back end syslog générique. Cet exemple utilise IBM Log Analysis. Vous pouvez choisir parmi différents plans. Pour comprendre comment obtenir les détails requis tels que le nom d'hôte et la clé d'ingestion, consultez la section Logging for Hyper Protect Virtual Servers for VPC.

2. Créez la section env

Veillez à ne pas oublier le symbole de barre verticale « | » si vous utilisez un contrat en texte brut. Elle n'est pas obligatoire si vous prévoyez de chiffrer la section.

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

3. Préparez le fichier docker-compose

En supposant que vous disposez des détails de journalisation, recherchez un fichier Docker Compose simple. L'exemple suivant présente un conteneur public NGINX. Créez un site docker-compose.yaml en vous inspirant de l'exemple.

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

4. Obtenez la version base64-encoded du fichier docker-compose

tar -czvf compose.tgz docker-compose.yaml

base64 -i compose.tgz > compose.b64

5. Créez la section Compose avec elle

  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. Remplir la section de charge de travail

Assurez-vous de ne pas oublier le symbole de la barre verticale (|) si vous utilisez un contrat en texte brut.

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. Votre contrat simple est prêt

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