La subsección auths

La sección auths consta de información sobre el registro del contenedor. Si se utiliza una imagen pública en el contrato, no necesita la sección auths porque no se necesitan credenciales. La subsección auths sólo es necesaria si las imágenes de contenedor son privadas. Esta subsección no tiene ninguna información de imagen, como se muestra en el ejemplo siguiente. Esta subsección debe contener el nombre del registro de imágenes y las credenciales como username-password para el mismo. La clave debe ser el nombre de host del Container Registry o la siguiente cadena para el registro de Docker predeterminado:

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

El siguiente fragmento de código muestra un ejemplo para IBM Cloud Registry. Para obtener más información sobre cómo utilizar la clave de API, consulte Utilización del software de cliente para autenticarse en la automatización.

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

La subsección compose

Consta de una subsección de archivado. La subsección de archivado contiene el archivo TGZ codificado en Base64 del archivo docker-compose.yaml. Puesto que la imagen de Hyper Protect Container Runtime utiliza Docker Engine y Docker Compose para iniciar el contenedor, primero se debe crear la información sobre el contenedor utilizando un archivo docker-compose estándar. Este archivo se archiva y se codifica c Base64, y el resultado de este proceso se proporciona como el valor de la subsección de archivo, dentro de la sección de redacción. Para obtener más información, consulte Visión general de Docker Compose.

Los puntos de montaje especificados bajo la información de volúmenes del archivo docker-compose pueden estar alineados con el punto de montaje de volumen especificado en la sección de carga de trabajo del contrato.

No se da soporte a la ejecución de una compilación como parte de un archivo de composición de docker. Asegúrese de que el archivo de composición de docker no tenga una sección build.

Los formatos "yaml" y "yml" están soportados para el archivo docker-compose. Consulta el siguiente ejemplo de un archivo docker-compose.

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

Existen casos de uso en los que no se conoce el registro cuando la sección de carga de trabajo está precodificada. Por ejemplo, cuando el proveedor de carga de trabajo desea permitir que el implementador utilice un espejo de registro o un registro privado Container Registry, es posible anular dinámicamente el registro y las credenciales de extracción. Este esfuerzo debe ser coordinado entre el proveedor de la carga de trabajo y el implementador. Para obtener más información, consulte Utilización de una referencia de registro dinámico.

Complete los siguientes pasos para obtener el Base64 archivo de almacenamiento codificado. El Base64 La salida está disponible en el compose.b64 archivo. Vaya a <COMPOSE_Folder> y ejecute los mandatos siguientes:

tar czvf compose.tgz docker-compose.yml

base64 -w0 compose.tgz > compose.b64

Asegúrese de que el archivo tgz de redacción contenga solo directorios y archivos normales. Los enlaces o conductos no están soportados.

Copie el contenido de compose.b64 como un valor de compose-> archive.

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

Para este ejemplo, obtendría una respuesta similar a la salida siguiente:

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

La subsección play

En el play subsección, puede definir la carga de trabajo a través de Descriptores de pod. Cada pod puede contener una o más definiciones de contenedor. Los descriptores pueden proporcionarse de una de las siguientes formas:

• En formato YAML sin formato en la subsección resources de play. Esta sección es una matriz de descriptores y da soporte a dos tipos de descriptores: Pods y ConfigMaps.

  El ejemplo siguiente ilustra cómo utilizar la sección 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
  

  El siguiente ejemplo ilustra cómo utilizar initcontainers con la sección 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
  

• En el archive subsección de play, el archivo es un Base64 archivo tar codificado y comprimido con gzip. Los pods o ConfigMaps se representan como archivos YAML, en el nivel superior de este archivo tar. El archivo también puede contener archivos adicionales y todos los archivos se extraen al sistema de archivos del host antes de que se inicien los Pods. El directorio de trabajo actual es el directorio en el que se han extraído los archivos, por lo que es posible utilizar un montaje de volumen con una vía de acceso relativa para montar los archivos o directorios del archivo YAML.

  Ejemplo:

  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
  

• En un formato de plantilla en la subsección templates de play. Esta sección es una matriz de descriptores en formato YAML. Las cápsulas o ConfigMaps pueden tener puntos de variabilidad (POV) que no se conocen en el momento de redactar los descriptores. Estos POV pueden representarse como plantillas y los valores se completan en el momento de la implementación a partir de la información del contrato. Utilizamos go templates como sintaxis de plantillas, que es la misma que se utiliza para diagramas de Helm, para que las plantillas se puedan intercambiar fácilmente con k8s. Damos soporte a los siguientes objetos de Built-In:

  • Entorno: este objeto contiene las variables de entorno fusionadas entre la carga de trabajo y la sección de entorno. El objeto está disponible como {{ .Env }}.

  Ejemplo:

  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
  

  La expresión {{ .Env REGISTRY }} hace referencia a la variable de entorno REGISTRY que en este ejemplo se define en la sección env del contrato.

  Las plantillas deben ser YAMLválidas, por lo que se debe escapar una expresión de sustitución si aparece como la primera parte de una serie. De lo contrario, choca con el mapeo de bloques sintaxis. Esto es diferente de las plantillas de control, en las que las expresiones se aplican a la representación textual del documento en lugar de a la representación del modelo.

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 subsección images

Docker ha anunciado la retirada de Docker Content Trust (DCT). Dado que DCT se basa en el legado Notario v1 marco, que ya no se mantiene activamente, no se considera una solución sostenible o preparada para el futuro para la firma y verificación de imágenes. En consecuencia, se anima a los clientes a abandonar la tecnología DCT y adoptar tecnologías de verificación y firma por imagen conformes con la OCI que se ajusten a las normas actuales de seguridad de la cadena de suministro. Puede migrar imágenes de contenedor a IBM Cloud Container Registry (ICR). ICR se integra con Red Hat Signing Service (RHS) como raíz de firma de confianza, lo que proporciona un modelo de confianza respaldado por el proveedor y se ajusta a las mejores prácticas actuales de seguridad de contenedores y cadena de suministro. Para más información, consulte Retirar Docker Content Trust.

La subsección images sólo está pensada para una imagen firmada.

<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 subsección workload- volumes

La sección volumes debe proporcionarse en el contrato sólo si un volumen de datos está conectado a la instancia en el momento de la creación. La información que se proporciona en esta sección se utiliza para montar el volumen de datos adjunto (proporcionado por el usuario) y posteriormente se cifra utilizando las "semillas" proporcionadas en las secciones workload y env. Puede proporcionar cualquier ruta de su elección para el campo "mount". La ruta que proporciona el usuario se utiliza internamente para montar el volumen de datos. La ruta de montaje que se proporciona en el contrato debe coincidir con la ruta que se proporciona en la sección de volúmenes del archivo docker-compose.yaml para que todos los datos asociados con la carga de trabajo del contenedor se almacenen en este volumen de datos.

La subsección volumes tiene soporte para el cifrado automático del volumen de datos con semillas proporcionadas por el usuario. Si un volumen de datos está conectado a la instancia de Hyper Protect Virtual Servers, se cifra automáticamente con las semillas que se proporcionan a través del campo "semilla" en las subsecciones volumes del contrato. Por lo tanto, se deben proporcionar dos semillas, una a través de la sección workload (por la persona de la carga de trabajo) y la otra a través de la sección env (por la persona del desplegador). Estas dos semillas se convierten internamente en secuencias UTF8 y, a continuación, se concatenan. Posteriormente, el hash (SHA256) de la secuencia concatenada se calcula como un hexdigest, que se utiliza como frase de contraseña LUKS para cifrar el volumen de datos.

Actualmente, las semillas env y workload requieren una longitud mínima de 3 caracteres. A partir de marzo de 2026, este mínimo aumentará a 15 caracteres. Cualquier valor de semilla inferior a 15 caracteres después de marzo de 2026 puede dar lugar a errores o a despliegues fallidos. Para evitar interrupciones, actualice lo antes posible todos los valores de las semillas a una longitud de al menos 15 caracteres. Las normas se definen en la sección siguiente.

A partir de marzo de 2026, deberás seguir estas normas para crear semillas:

• No se permiten espacios.
• Debe tener al menos 15 caracteres. A continuación se indican los caracteres permitidos:
  • Letras minúsculas (a-z)
  • Letras mayúsculas (A-Z)
  • Números (0-9)
  • Caracteres especiales !@#$%^&*(),.?":{}|<>_-

Puedes utilizar el siguiente comando para validar el hexdigest:

echo -n "seed1seed2" | sha256sum

Aquí puede aprender cómo se puede proporcionar la "semilla" en la sección de carga de trabajo del contrato. Para obtener más información sobre cómo se puede proporcionar la entrada "semilla" a través de la sección env, consulte La sección env. Es obligatorio proporcionar ambas semillas para el cifrado. El cifrado falla si sólo se proporciona una instancia de semilla.

Puede añadir un mayor nivel de protección y control mediante cifrado a sus datos en reposo mediante la integración con Hyper Protect Crypto Services. A partir de ibm-hyper-protect-container-runtime-1-0-s390x-11, puede utilizar Hyper Protect Crypto Services para generar un valor aleatorio como tercera semilla y envolverlo con su clave raíz. La frase de contraseña LUKS se genera utilizando tres semillas: la semilla en la partición de metadatos y las dos semillas del contrato. Puede obtener información adicional consultando Protección de datos.

El siguiente fragmento de código es un ejemplo para la sección de volúmenes:

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

A partir de la versión de ibm-hyper-protect-container-runtime-1-0-s390x-9 imagen HPCR, para las Hyper Protect Virtual Servers nuevas instancias VPC, el volumen de datos se divide en dos partes. La primera partición ( 100Mib ) está reservada para metadatos internos; la segunda partición permanece como volumen de datos para la carga de trabajo. Sólo se particionan los volúmenes nuevos y no puede utilizar el volumen particionado con una versión anterior de la imagen HPCR. El suministro con un volumen cifrado existente también funciona. La diferencia es que el volumen existente no se particiona, y también puede volver a una imagen más antigua con este volumen.

A partir de ibm-hyper-protect-container-runtime-1-0-s390x-12, el desplegador y el proveedor pueden utilizar la característica "rotación de semillas". Se proporciona una opción para rodar o rotar las semillas para aumentar la postura de seguridad, o si la semilla está comprometida. Cuando el desplegador o el proveedor o ambos desean retrotraer las semillas, la información de semilla actual debe especificarse en el parámetro previousSeed, y la nueva información de semilla debe especificarse en el parámetro seed.

El siguiente fragmento de código es un ejemplo para la sección de volúmenes:

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

A partir de ibm-hyper-protect-container-runtime-1-0-s390x-13, puede conectar varios volúmenes al iniciar la instancia de servidor virtual. Los volúmenes que se adjuntan cuando la instancia se está ejecutando se ignoran.

El siguiente fragmento de código es un ejemplo para la sección de volúmenes:

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 subsección 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 subsección env- volumes

Lea la subsección workload-volumes de la sección de carga de trabajo antes de continuar con esta sección. Como ya se ha mencionado, para el cifrado de disco automático del volumen de datos adjunto, debe proporcionar dos semillas de cliente, una en la subsección workload- volumes y la otra en la subsección env- volumes. Las semillas pueden ser cualquier texto aleatorio de su elección.

Vea el siguiente ejemplo de la subsección env- volumes:

volumes:
  test:
    seed: "seed_value_with_minimum_15_characters"

Cuando utiliza la característica "rolado de semillas", puede utilizar el fragmento de código siguiente como ejemplo:

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

Cuando se utilizan varios volúmenes, el desplegador debe asegurarse de que los volúmenes se crean por adelantado y también especificar el ID de volumen en el archivo de contrato. De lo contrario, debe especificarse el nombre de volumen y el volumen debe crearse con el mismo nombre. Si no se especifican ambos, la tecla de volumen se considera como el nombre del volumen y el volumen debe crearse con el mismo nombre mientras se crea la instancia del servidor virtual o antes. El siguiente fragmento es un ejemplo:

 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"

Donde:

• Nombre del volumen: es el nombre que especificó cuando creó el volumen en el VPC.
• ID de volumen: es el ID de volumen generado por el sistema del volumen creado.
• Clave de volumen: es el nombre de volumen exclusivo para cada volumen.

La clave de volumen debe ser la misma que la clave en la subsección de carga de trabajo - volúmenes.

Como se ha mencionado, puede integrar con Hyper Protect Crypto Services para generar una tercera semilla y envolverla con la clave raíz. Vea el ejemplo siguiente. Puede obtener información adicional consultando Protección de datos.

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

Subsección signingKey

Para obtener más información sobre cómo utilizar signingKey, consulte Firma de contrato.

Subsección env

• Si se utilizan descriptores Pod en la sección workload:

  Consulte el ejemplo del formato de plantilla en la subsección play.

• Si se utiliza un archivo de composición de docker en la sección workload:

  Si el archivo de composición de docker tiene una sección de entorno, puede utilizar el fragmento de código siguiente como ejemplo:

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

  Cuando el archivo de composición de Docker tiene una sección de entorno, como se muestra en el ejemplo anterior, puede pasar los valores en la sección de configuración ( env ) del implementador. El ejemplo siguiente muestra cómo especificar los valores para las variables env:

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

Descarga del certificado de cifrado y extracción de la clave pública

1. Descargue el certificado. En la siguiente tabla se indican las fechas de caducidad de los certificados de cifrado y las fechas de fin de soporte o de obsolescencia de las imágenes, según la versión de cada una.

Nota

• Obsoleto- Puede utilizar la imagen para crear una instancia desde la CLI IBM Cloud. El estado obsoleto puede desalentar el uso de la imagen antes de que su estado cambie a obsoleto. El catálogo de imágenes mantiene siempre las dos versiones de imagen más recientes: n y n-1. Cuando una nueva versión ( n+1 ) está disponible, el sistema deja obsoleta la versión más antigua ( n-1 ).
• Obsoleto: Cuando el certificado asociado a la imagen caduca, la imagen no está disponible para aprovisionar una instancia.
• Descargue siempre los certificados de cifrado correspondientes a la imagen y cifre los contratos.

Para comprobar la imagen en desuso o el estado obsoleto, también puede utilizar el mandato IBM Cloud image list.

Puede consultar la documentación del mandato de lista de imágenes para obtener el estado de la imagen.

2. Valide el certificado de cifrado siguiendo las instrucciones del tema Validación del certificado de cifrado del contrato.

Creación de la sección workload cifrada de un contrato

El valor de cualquier sección de un contrato puede ser texto sin formato o cifrado. Complete los siguientes pasos en un sistema de cifrado de claves asimétricas ( Ubuntu ) para cifrar la sección de carga de trabajo utilizada en un contrato:

1. Cree el archivo docker-compose.yaml basándose en los requisitos de carga de trabajo. Por ejemplo:

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

   Para obtener más información, consulte Visión general de Docker Compose.

2. Cree la sección de carga de trabajo del contrato y añada el contenido en el archivo workload.yaml.

   A continuación se muestra un ejemplo ​workload.yaml de:

   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. Exporte la vía de acceso completa del archivo workload.yaml y 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. Utiliza el siguiente comando para crear una contraseña aleatoria. El contrato se cifra mediante AES simétrico con una contraseña aleatoria.

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

5. A partir de OpenSSL 3.0, el comando OpenSSL rsautl queda obsoleto y se sustituye por el comando pkeyutl. Utilice uno de los siguientes comandos para cifrar la contraseña con ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt:

   • Uso de rsautl (obsoleto):

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

   • Utilizando pkeyutl (recomendado):

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

6. Utilice el mandato siguiente para cifrar el archivo workload.yaml con una contraseña aleatoria:

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

7. Utilice el mandato siguiente para obtener la sección cifrada del contrato:

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

8. Obtenga la salida del paso 7 y añádala al archivo user-data.yaml.

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

   El prefijo hyper-protect-basic es obligatorio.

Creación de la sección env cifrada de un contrato

Complete los siguientes pasos en un sistema Ubuntu para cifrar la sección env utilizada en un contrato:

1. Cree la sección env del contrato y añada el contenido en el archivo env.yaml.

   A continuación se muestra un ejemplo 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. Exporte la vía de acceso completa del archivo env.yaml y 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. Utiliza el siguiente comando para crear una contraseña aleatoria:

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

4. A partir de OpenSSL 3.0, el comando OpenSSL rsautl queda obsoleto y se sustituye por el comando pkeyutl. Utilice uno de los siguientes comandos para cifrar la contraseña con ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt:

   • rsautl (obsoleto):

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

   • pkeyutl (recomendado):

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

5. Utilice el mandato siguiente para cifrar env.yaml con una contraseña aleatoria:

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

6. Utilice el mandato siguiente para obtener la sección cifrada del contrato:

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

7. Para cifrar la sección de carga de trabajo, consulte Creación de la sección workload cifrada de un contrato.

8. Obtenga la salida del paso 6 y añádala al archivo user-data.yaml.

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

Registros de aviso de caducidad de certificados de cifrado y atestación

HPVS registra mensajes de advertencia en el servicio de registro configurado sobre certificados de cifrado y atestación próximos y caducados.

A continuación figura el calendario de notificaciones:

• 30 días antes de la expiración: Se genera un mensaje de advertencia una vez cada 24 horas, notificando que el certificado caducará en un mes.

  Ejemplo:

  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 días antes de la fecha de caducidad: Los mensajes de advertencia se registran cada 12 horas a medida que se acerca la fecha de caducidad, resaltando la necesidad de actuar.

  Ejemplo:

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

• Tras la caducidad del certificado: Si el certificado ha caducado, HPVS registra mensajes de advertencia cada 4 horas hasta que se actualice la imagen HPVS.

  Ejemplo:

  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. Obtener los detalles de la instancia de registro

Puede configurar el registro con IBM Log Analysis o un programa de fondo syslog genérico. Este ejemplo utiliza IBM Log Analysis. Puede elegir entre diferentes planes. Para comprender cómo obtener los detalles necesarios, como el nombre de host y la clave de ingestión, consulte Registro para Hyper Protect Virtual Servers para VPC.

2. Cree la sección env

Asegúrese de no omitir el símbolo de barra vertical «|» si utiliza un contrato de texto sin formato. No es necesario si tiene previsto cifrar la sección.

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

3. Preparar el archivo docker-compose

Suponiendo que tiene los detalles de registro, busque un archivo de composición de docker simple. El siguiente ejemplo tiene un contenedor público NGINX. Cree un docker-compose.yaml utilizando el ejemplo.

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

4. Obtener la versión base64-encoded del archivo docker-compose

tar -czvf compose.tgz docker-compose.yaml

base64 -i compose.tgz > compose.b64

5. Crear la sección de composición con ella

  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. Llenar la sección de carga de trabajo

Asegúrese de que no se le pasa el símbolo de barra vertical (|) si está utilizando un contrato de texto sin formato.

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. Su contrato simple está listo

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