A subseção auths

A seção auths consiste em informações sobre o registro do contêiner. Se uma imagem pública for usada no contrato, você não precisará da seção auths porque nenhuma credencial é necessária A subseção auths é necessária apenas se as imagens do container forem privadas. Esta subseção não possui nenhuma informação de imagem, como mostrado na amostra a seguir. Esta subseção precisa conter o nome do registro de imagem e as credenciais como username-password para o mesmo. A chave deve ser o nome do host do Container Registry ou a seguinte string para o registro do Docker padrão:

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

O trecho a seguir mostra um exemplo para o Registro IBM Cloud. Para obter mais informações sobre o uso da chave API, consulte Usando software cliente para autenticar na automação.

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

A subseção compose

Consiste em uma subseção de arquivo. A subseção de arquivo contém o arquivo de arquivo TGZ do Base64 codificado do arquivo docker-compose.yaml. Como a imagem do Hyper Protect Container Runtime usa Docker Engine e Docker Compose para iniciar o contêiner, as informações sobre o contêiner devem primeiro ser criadas usando um arquivo docker-compose padrão. Esse arquivo é então arquivado e codificado em Base64, e a saída desse processo é fornecida como o valor da subseção archive, na seção compose. Para obter mais informações, consulte Visão Geral do Docker Compose.

Os pontos de montagem especificados sob as informações de volumes do arquivo docker-compose podem estar alinhados com o ponto de montagem do volume especificado na seção de carga de trabalho do contrato.

Executar uma construção como parte de um arquivo do Docker Compose não é suportado. Certifique-se de que seu arquivo do Docker Compose não tenha uma seção build

Ambos os formatos "yaml" e "yml" são suportados para arquivo de compose docker. Veja o exemplo a seguir de um arquivo docker-compose.

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

Existem casos de uso em que o registro não é conhecido quando a seção de carga de trabalho é pré-criptografada. Por exemplo, quando o provedor de carga de trabalho deseja permitir que o implantador use um espelho de registro ou um privado Container Registry, é possível substituir dinamicamente o registro e as credenciais de pull. Esse esforço precisa ser coordenado entre o provedor de carga de trabalho e o implantador. Para obter mais informações, consulte Usando uma referência de registro dinâmico..

Conclua as etapas a seguir para obter o Base64 arquivo compactado codificado. O Base64 a saída está disponível no compose.b64 arquivo. Acesse o <COMPOSE_Folder> e execute os seguintes comandos:

tar czvf compose.tgz docker-compose.yml

base64 -w0 compose.tgz > compose.b64

Certifique-se de que o arquivo composto tgz contenha apenas diretórios e arquivos regulares. Links ou canais não são suportados.

Copie o conteúdo de compose.b64 como um valor de compose-> arquivo.

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

Para esse exemplo, você veria uma resposta semelhante à saída a seguir:

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

A subseção play

No play subseção, você pode definir a carga de trabalho por meio Descritores de pod. Cada pod pode conter uma ou mais definições do contêiner Os descritores podem ser fornecidos de uma das seguintes maneiras:

• No formato YAML simples na subseção resources de play.. Esta seção é uma matriz de descritores e suporta dois tipos de descritores: Pods e ConfigMaps..

  O exemplo a seguir ilustra como usar a seção 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
  

  O exemplo a seguir ilustra como usar a seção initcontainers com a seção 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
  

• No archive subseção de play, o arquivo é um Base64 arquivo tar codificado e compactado. Os Pods ou ConfigMaps são representados como arquivos YAML, no nível superior nesse arquivo tar O arquivo também pode conter arquivos extras e todos os arquivos são extraídos para o sistema de arquivos do host antes de os pods serem iniciados. O diretório ativo atual é o diretório no qual os arquivos foram extraídos, portanto, é possível usar uma montagem de volume com um caminho relativo para montar os arquivos ou diretórios do arquivo YAML.

  Exemplo:

  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
  

• Em um formato de modelo na subseção templates de play. Esta seção é uma matriz de descritores no formato YAML Os pods ou ConfigMaps podem ter pontos de variabilidade (POV) que não são conhecidos no momento da redação dos descritores. Esses POVs podem ser representados como modelos e os valores são preenchidos no momento da implantação a partir das informações do contrato. Usamos go templates como a sintaxe de modelagem, que é a mesma usada para gráficos do helm, portanto, os modelos podem ser trocados facilmente com k8s. Suportamos os seguintes objetos Built-In:

  • Ambiente: esse objeto contém as variáveis de ambiente mescladas entre a carga de trabalho e a seção de ambiente. O objeto está disponível como {{ .Env }}..

  Exemplo:

  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
  

  A expressão {{ .Env REGISTRY }} faz referência à variável de ambiente REGISTRY que neste exemplo é definida na seção env do contrato.

  Os modelos precisam ser válidos YAML, portanto, uma expressão de substituição deverá ser escapada se ela aparecer como a primeira parte de uma sequência de caracteres Caso contrário, colide com o mapeamento de blocos sintaxe. Isso é diferente dos modelos de capacete, em que as expressões são aplicadas à representação textual do documento em vez da representação do 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

A subseção images

Docker anunciou a aposentadoria do Docker Content Trust (DCT). Como a DCT foi desenvolvida com base no legado Notário v1 framework, que não é mais mantido ativamente, ela não é considerada uma solução sustentável ou pronta para o futuro para assinatura e verificação de imagens. Como resultado, os clientes são incentivados a abandonar a DCT e adotar tecnologias de verificação e assinatura de imagem em conformidade com a OCI que se alinham aos padrões atuais de segurança da cadeia de suprimentos. Você pode migrar imagens de contêineres para IBM Cloud Container Registry (ICR). O ICR integra-se ao Red Hat Signing Service (RHS) como sua raiz confiável de assinatura, fornecendo um modelo de confiança apoiado pelo fornecedor e alinhamento com as práticas recomendadas contemporâneas de segurança de contêineres e cadeia de suprimentos. Para obter mais informações, consulte Retirada do Docker Content Trust.

A subseção images é significada apenas para uma imagem que é assinada.

<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

A subseção workload- volumes

A seção volumes precisa ser fornecida no contrato somente se um volume de dados for anexado à instância no momento da criação. As informações fornecidas nesta seção são usadas para montar o volume de dados anexado (fornecido pelo usuário) e, posteriormente, são criptografadas usando as "sementes" fornecidas nas seções workload e env. Você pode fornecer qualquer caminho de sua escolha para o campo "mount". O caminho fornecido pelo usuário é usado internamente para montar o volume de dados. O caminho de montagem fornecido no contrato deve corresponder ao caminho fornecido na seção de volumes do arquivo docker-compose.yaml para que todos os dados associados à carga de trabalho do contêiner sejam armazenados nesse volume de dados.

A subseção volumes tem suporte para criptografia automática do volume de dados com valores iniciais fornecidos pelo usuário. Se um volume de dados for conectado à instância do Hyper Protect Virtual Servers, ele será criptografado automaticamente com os valores iniciais que são fornecidos por meio do campo "valor inicial" nas subseções volumes do contrato. Assim, dois valores iniciais devem ser fornecidos, um por meio da seção workload (pela persona de carga de trabalho) e outro por meio da seção env (pela persona do implementador). Esses dois valores iniciais são convertidos internamente para sequências UTF8 e, em seguida, concatenados Posteriormente, o hash (SHA256) da sequência concatenada é calculado como uma compilação, que é usada como a passphrase do LUKS para criptografar o volume de dados.

Atualmente, as sementes env e workload exigem um comprimento mínimo de 3 caracteres. A partir de março de 2026, esse mínimo será aumentado para 15 caracteres. Qualquer valor de semente com menos de 15 caracteres após março de 2026 pode resultar em erros ou falhas na implementação. Para evitar interrupções, atualize todos os valores de semente para um comprimento de pelo menos 15 caracteres o mais rápido possível. As regras são definidas na seção a seguir.

A partir de março de 2026, você deverá seguir estas regras para criar sementes:

• Nenhum espaço permitido.
• Deve ter pelo menos 15 caracteres. A seguir estão os caracteres permitidos:
  • Letras minúsculas (a-z)
  • Letras maiúsculas (A-Z)
  • Números (0-9)
  • Caracteres especiais !@#$%^&*(),.?":{}|<>_-

Você pode usar o seguinte comando para validar o hexdigest:

echo -n "seed1seed2" | sha256sum

Aqui você pode aprender como a "semente" pode ser fornecida na seção de carga de trabalho do contrato. Para obter mais informações sobre como a entrada "seed" pode ser fornecida através da seção env, consulte A seção env. É obrigatório fornecer ambas as sementes para criptografia. A criptografia falha se apenas uma das sementes for fornecida instância embarca para baixo.

Você pode adicionar um nível mais alto de proteção e controle de criptografia aos seus dados em repouso, integrando-os com Hyper Protect Crypto Services. A partir de ibm-hyper-protect-container-runtime-1-0-s390x-11, você pode usar Hyper Protect Crypto Services para gerar um valor aleatório como a terceira semente e envolvê-lo com sua chave raiz. A passphrase do LUKS é gerada usando três valores iniciais-o valor inicial na partição de metadados e os dois valores iniciais do contrato. Para obter mais informações, consulte Protegendo seus dados.

O snippet a seguir é um exemplo para a seção de volumes:

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

A partir da versão da imagem ibm-hyper-protect-container-runtime-1-0-s390x-9 HPCR, para Hyper Protect Virtual Servers novas instâncias VPC, o volume de dados é particionado em duas partes. A primeira partição ( 100Mib ) é reservada para metadados internos; a segunda partição permanece como o volume de dados para carga de trabalho. Somente novos volumes são particionados e não é possível usar o volume particionado com uma versão mais antiga da imagem HPCR. O fornecimento com um volume criptografado existente também funciona A diferença é que o volume existente não é particionado e também é possível voltar para uma imagem mais antiga com esse volume..

A partir do ibm-hyper-protect-container-runtime-1-0-s390x-12, o implementador e o provedor podem usar o recurso de "rolagem de valores iniciais". Uma opção é fornecida para rolar ou girar as sementes para aumentar a postura de segurança ou se a semente estiver comprometida. Quando o implementador ou o provedor ou ambos desejam rolar os valores iniciais, as informações de valor inicial atuais devem ser especificadas no parâmetro previousSeed e as novas informações de valor inicial devem ser especificadas no parâmetro seed.

O snippet a seguir é um exemplo para a seção de volumes:

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

A partir do ibm-hyper-protect-container-runtime-1-0-s390x-13, é possível anexar vários volumes quando você ativa a instância de servidor virtual Os volumes que são anexados quando a instância está em execução são ignorados.

O snippet a seguir é um exemplo para a seção de 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"

A subseção 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)

A subseção env- volumes

Leia a subseção carga de trabalho-volumes da seção de carga de trabalho antes de continuar com esta seção. Conforme já mencionado, para criptografia de disco automática do volume de dados conectado, deve-se fornecer dois valores iniciais do cliente, um na subseção workload- volumes e o outro na subseção env- volumes. As sementes podem ser qualquer texto aleatório de sua escolha.

Veja o exemplo a seguir da subseção env- volumes:

volumes:
  test:
    seed: "seed_value_with_minimum_15_characters"

Quando estiver usando o recurso "rolagem de valores iniciais", é possível usar o fragmento a seguir como um exemplo:

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

Ao usar diversos volumes, o implementador deve assegurar que os volumes sejam criados antecipadamente e também especificar o ID do volume no arquivo de contrato. Caso contrário, o nome do volume deverá ser especificado e o volume deverá ser criado com o mesmo nome.. Se ambos não forem especificados, a chave do volume será considerada como o nome do volume e o volume deverá ser criado com o mesmo nome durante ou antes da criação da instância do servidor virtual. O trecho a seguir é um exemplo:

 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"

Em que:

• Nome do volume: é o nome que você especificou quando criou o volume na VPC.
• ID do Volume: é o ID do volume gerado pelo sistema do volume criado.
• Chave do volume: é o nome do volume exclusivo para cada volume.

A chave do volume deve ser a mesma da chave na subseção carga de trabalho - volumes.

Conforme mencionado, é possível integrar com o Hyper Protect Crypto Services para gerar um terceiro valor inicial e agrupá-lo com sua chave raiz. Consulte o exemplo a seguir. Para obter mais informações, consulte Protegendo seus dados.

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

signingKey subseção

Para obter mais informações sobre como usar o signingKey, consulte Assinatura de contrato.

env subseção

• Se os descritores de Pod forem usados na seção workload:

  Consulte o exemplo para o formato do modelo em a subseção play

• Se um arquivo de composição do Docker for usado na seção workload:

  Se o docker compor arquivo tiver uma seção de ambiente, você pode usar o seguinte trecho como exemplo:

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

  Quando o arquivo docker compose tem uma seção de ambiente, como mostrado no exemplo anterior, você pode passar os valores na seção env do implantador. O exemplo a seguir mostra como especificar os valores para as variáveis env:

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

Baixando o certificado de criptografia e extraindo a chave pública

1. Faça o download do certificado. A tabela a seguir lista as datas de validade dos certificados de criptografia e as datas de descontinuação/obsolescência das imagens, com base na versão da imagem.

Nota

• Preterido- Você pode usar a imagem para criar uma instância a partir da CLI do site IBM Cloud. O status depreciado pode desencorajar o uso da imagem antes que seu status mude para obsoleto. O catálogo de imagens sempre mantém as duas versões mais recentes da imagem: n e n-1. Quando uma nova versão ( n+1 ) está disponível, o sistema substitui a versão mais antiga ( n-1 ).
• Obsoleta: Depois que o certificado associado à imagem expira, a imagem não fica disponível para provisionar uma instância.
• Sempre faça o download dos certificados de criptografia que correspondem à imagem e criptografe os contratos.

Para verificar a descontinuação da imagem ou o status obsoleto, também é possível utilizar o comando IBM Cloud image list.

É possível consultar a documentação para o comando image list para obter o status da imagem.

2. Valide o certificado de criptografia seguindo as instruções do tópico Validando o certificado de criptografia do contrato.

Criando a seção criptografada workload de um contrato

O valor de qualquer seção em um contrato pode ser texto simples ou criptografado. Conclua as etapas a seguir em um sistema Ubuntu para criptografar a seção de carga de trabalho usada em um contrato:

1. Crie o arquivo docker-compose.yaml com base em seus requisitos de carga de trabalho. Por exemplo,

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

   Para obter mais informações, consulte Visão Geral do Docker Compose.

2. Crie a seção de carga de trabalho do contrato e inclua o conteúdo no arquivo workload.yaml.

   A seguir, um exemplo 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. Exporte o caminho completo do arquivo workload.yaml e 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. Use o comando a seguir para criar uma senha aleatória. O contrato é criptografado por meio de AES simétrico com uma senha aleatória.

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

5. A partir de OpenSSL 3.0, o subcomando OpenSSL rsautl está obsoleto e está sendo substituído pelo subcomando pkeyutl. Use um dos seguintes comandos para criptografar a senha com ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt:

   • Usando rsautl (obsoleto):

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

   • Usando o site pkeyutl (recomendado):

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

6. Use o seguinte comando para criptografar o arquivo workload.yaml com uma senha aleatória:

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

7. Use o comando a seguir para obter a seção criptografada do contrato:

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

8. Obter a saída da etapa 7 e adicioná-la ao arquivo user-data.yaml.

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

   O prefixo hyper-protect-basic é obrigatório.

Criando a seção criptografada env de um contrato

Conclua as etapas a seguir em um sistema Ubuntu para criptografar a seção env usada em um contrato:

1. Crie a env seção do contrato e inclua o conteúdo no arquivo env.yaml..

   A seguir, um exemplo 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 o caminho completo do arquivo env.yaml e 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. Use o seguinte comando para criar uma senha aleatória:

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

4. A partir de OpenSSL 3.0, o subcomando OpenSSL rsautl está obsoleto e está sendo substituído pelo subcomando pkeyutl. Use um dos seguintes comandos para criptografar a senha com 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. Use o seguinte comando para criptografar env.yaml com uma senha aleatória:

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

6. Use o comando a seguir para obter a seção criptografada do contrato:

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

7. Para criptografar a seção de carga de trabalho, consulte Criando a seção criptografada workload de um contrato.

8. Obter a saída da etapa 6 e adicioná-la ao arquivo user-data.yaml.

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

Registros de aviso de expiração de certificados de criptografia e atestação

O HPVS registra mensagens de aviso no serviço de registro configurado sobre certificados de criptografia e de atestado futuros e expirados.

O cronograma de notificação é o seguinte:

• 30 dias antes da expiração: Uma mensagem de aviso é gerada uma vez a cada 24 horas, notificando que o certificado expirará em um mês.

  Exemplo:

  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 dias antes do vencimento: Mensagens de aviso são registradas a cada 12 horas à medida que a data de expiração se aproxima, destacando a necessidade de ação.

  Exemplo:

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

• Após a expiração do certificado: Se o certificado tiver expirado, o HPVS registrará mensagens de aviso a cada 4 horas até que a imagem do HPVS seja atualizada.

  Exemplo:

  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. Obtenha os detalhes de sua instância de registro de registro

É possível configurar a criação de log com o IBM Log Analysis ou um backend de syslog genérico. Este exemplo usa o IBM Log Analysis Você pode escolher entre diferentes planos. Para entender como você obtém os detalhes necessários, como o nome do host e a chave de ingestão, consulte Registro em log para Hyper Protect Virtual Servers para VPC.

2. Crie a seção env

Certifique-se de não perder o símbolo de pipe '|' se estiver usando um contrato de texto simples. Ele não é necessário se você estiver planejando criptografar a seção.

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

3. Prepare o arquivo docker-compose

Supondo que você tenha os detalhes da criação de log, encontre um arquivo de compose de docker simples. O exemplo a seguir tem um contêiner público NGINX. Crie um docker-compose.yaml usando o exemplo.

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

4. Obtenha a versão base64-encoded do arquivo docker-compose

tar -czvf compose.tgz docker-compose.yaml

base64 -i compose.tgz > compose.b64

5. Crie a seção de composição com ela

  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. Preencher a seção de carga de trabalho

Certifique-se de não perder o símbolo de pipe (|) se estiver usando um contrato de texto simples.

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. Seu contrato simples está pronto

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