La sottosezione auths

La sezione auths è costituita da informazioni sul registro del contenitore. Se nel contratto viene utilizzata un'immagine pubblica, non hai bisogno della sezione auths perché non è richiesta alcuna credenziale. La sottosezione auths è richiesta solo se le immagini del contenitore sono private. Questa sottosezione non contiene informazioni sull'immagine, come mostrato nel seguente esempio. Questa sottosezione deve contenere il nome del registro immagini e le credenziali come username - password per lo stesso. La chiave deve essere il nome host del file Container Registry o la seguente stringa per il registro docker predefinito:

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

Il seguente frammento mostra un esempio per IBM Cloud Registry. Per ulteriori informazioni sull'uso della chiave API, vedi Utilizzo del software client per l'autenticazione nell'automazione.

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

La sottosezione compose

Si compone di una sottosezione di archivio. La sottosezione di archiviazione contiene l'archivio file TGZ codificato Base64 del file docker-compose.yaml. Poiché l'immagine Hyper Protect Container Runtime utilizza Docker Engine e Docker Compose per avviare il contenitore, le informazioni sul contenitore devono prima essere create utilizzando un file docker - compose standard. Questo file viene quindi archiviato e codificato con l' Base64, e l'output di questo processo viene fornito come valore alla sottosezione dell'archivio, all'interno della sezione di composizione. Per ulteriori informazioni, vedi Panoramica di Docker Compose.

I punti di montaggio specificati nelle informazioni sui volumi del file docker - compose potrebbero essere allineati con il punto di montaggio del volume specificato nella sezione del carico di lavoro del contratto.

L'esecuzione di un build come parte di un file di composizione docker non è supportato. Assicurati che il tuo file docker compose non abbia una sezione build.

Entrambi i formato "yaml" e "yml" sono supportati per il file docker-compose. Si veda il seguente esempio di file docker-compose.

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

Esistono casi in cui il registro non è noto quando la sezione del carico di lavoro è pre-crittografata. Ad esempio, quando il fornitore del carico di lavoro desidera consentire al distributore di utilizzare un mirror del registro o un privato Container Registry, è possibile sovrascrivere dinamicamente il registro e le credenziali di pull. Questo sforzo deve essere coordinato tra il fornitore del carico di lavoro e l'addetto all'implementazione. Per ulteriori informazioni, consultare Utilizzo di un riferimento del registro dinamico.

Completa i seguenti passaggi per ottenere il file Base64 file di archivio codificato. IL Base64 l'output è disponibile in compose.b64 file. Passare a <COMPOSE_Folder> ed eseguire questi comandi:

tar czvf compose.tgz docker-compose.yml

base64 -w0 compose.tgz > compose.b64

Assicurati che il file tgz di composizione contenga solo directory e file normali. I collegamenti o i pipe non sono supportati.

Copiare il contenuto di compose.b64 come valore di compose -> archive.

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

Per questo esempio, dovresti vedere una risposta simile al seguente output:

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

La sottosezione play

Nel play sottosezione attraverso la quale è possibile definire il carico di lavoro Descrittori dei pod. Ogni pod può contenere una o più definizioni del contenitore. I descrittori possono essere forniti in uno dei seguenti modi:

• In formato YAML normale nella sottosezione resources di play. Questa sezione è un array di descrittori e supporta due tipi di descrittori: Pods e ConfigMaps.

  Il seguente esempio illustra come utilizzare la sezione 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'esempio seguente illustra l'uso di initcontainers con la sezione 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
  

• Nel archive sottosezione di play, l'archivio è a Base64 file tar codificato e compresso con gzip. I pod o ConfigMaps sono rappresentati come file YAML, al livello superiore in questo file tar. Il file potrebbe contenere anche file aggiuntivi e tutti i file vengono estratti nel file system host prima dell'avvio dei Pod. La directory di lavoro corrente è la directory in cui sono stati estratti i file, quindi è possibile utilizzare un montaggio di volume con un percorso relativo per montare i file o le directory dal file YAML.

  Esempio:

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

• In un formato modello nella sottosezione templates di play. Questa sezione è un array di descrittori in formato YAML. I pod o ConfigMaps possono avere punti di variabilità (POV) che non sono noti al momento della stesura dei descrittori. Questi POV possono essere rappresentati come modelli e i valori vengono completati al momento della distribuzione a partire dalle informazioni contenute nel contratto. Utilizziamo i template go come sintassi di template, che è la stessa utilizzata per i grafici helm, quindi i template possono facilmente essere scambiati con k8s. Sono supportati i seguenti oggetti Built-In:

  • Ambiente: questo oggetto contiene le variabili di ambiente come unite tra il carico di lavoro e la sezione ambiente. L'oggetto è disponibile come {{ .Env }}.

  Esempio:

  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'espressione {{ .Env REGISTRY }} fa riferimento alla variabile di ambiente REGISTRY che in questo esempio è definita nella sezione env del contratto.

  I modelli devono essere validi YAML, quindi è necessario eseguire l'escape di un'espressione di sostituzione se viene visualizzata come prima parte di una stringa. Altrimenti si scontra con il mappatura dei blocchi sintassi. Questo è diverso dai modelli di timone in cui le espressioni vengono applicate alla rappresentazione testuale del documento invece che alla rappresentazione del modello.

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 sottosezione images

Docker ha annunciato il ritiro di Docker Content Trust (DCT). Poiché il DCT è basato su **Quadro notarile v1 **, che non viene più mantenuto attivamente, non è considerato una soluzione pronta per il futuro o sostenibile per la firma e la verifica delle immagini. Di conseguenza, i clienti sono incoraggiati ad abbandonare il DCT e ad adottare tecnologie di firma e verifica delle immagini conformi all'OCI e in linea con gli attuali standard di sicurezza della catena di fornitura. È possibile migrare le immagini dei container su IBM Cloud Container Registry (ICR). L'ICR si integra con il servizio di firma Red Hat (RHS) come radice di firma affidabile, fornendo un modello di fiducia sostenuto dal fornitore e allineandosi alle migliori pratiche contemporanee in materia di sicurezza dei container e della catena di fornitura. Per ulteriori informazioni, vedere Ritiro di Docker Content Trust.

La sottosezione images è intesa solo per un'immagine firmata.

<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 sottosezione workload- volumes

La sezione volumes deve essere fornita nel contratto solo se un volume di dati è collegato all'istanza al momento della creazione. Le informazioni fornite in questa sezione vengono utilizzate per montare il volume dati allegato (fornito dall'utente) e vengono successivamente crittografate utilizzando i "semi" forniti nelle sezioni workload e env. Puoi fornire qualsiasi percorso di tua scelta per il campo "mount". Il percorso fornito dall'utente viene utilizzato internamente per montare il volume di dati. Il percorso di montaggio fornito nel contratto deve corrispondere al percorso fornito nella sezione volumi del file di configurazione del sistema ( docker-compose.yaml ) in modo che tutti i dati associati al carico di lavoro del container siano memorizzati in questo volume di dati.

La sottosezione volumes ha il supporto per la crittografia automatica del volume di dati con le origini fornite dall'utente. Se un volume di dati è collegato all'istanza Hyper Protect Virtual Servers, viene crittografato automaticamente con i valori di inizializzazione forniti tramite il campo "seed" nelle sottosezioni volumes del contratto. Pertanto, è necessario fornire due elementi di inizializzazione, uno tramite la sezione workload (dalla persona del carico di lavoro) e l'altro tramite la sezione env (dalla persona del distributore). Questi due elementi di inizializzazione vengono convertiti internamente in sequenze UTF8 e concatenati. Successivamente, l'hash (SHA256) della sequenza concatenata viene calcolato come un hexdigest, che viene utilizzato come passphrase LUKS per crittografare il volume di dati.

Attualmente, i semi di env e workload richiedono una lunghezza minima di 3 caratteri. A partire da marzo 2026, questo minimo sarà portato a 15 caratteri. Qualsiasi valore di seme inferiore a 15 caratteri dopo il marzo 2026 può causare errori o distribuzioni non riuscite. Per evitare interruzioni, aggiornare al più presto tutti i valori dei semi con una lunghezza di almeno 15 caratteri. Le regole sono definite nella sezione seguente.

A partire da marzo 2026, dovrete seguire queste regole per creare semi:

• Gli spazi non sono consentiti.
• Deve avere almeno 15 caratteri. I caratteri ammessi sono i seguenti:
  • Lettere minuscole (a-z)
  • Lettere maiuscole (A-Z)
  • Numeri (0-9)
  • Caratteri speciali !@#$%^&*(),.?":{}|<>_-

È possibile utilizzare il seguente comando per convalidare l'hexdigest:

echo -n "seed1seed2" | sha256sum

Qui puoi imparare come il "seed" può essere fornito nella sezione del carico di lavoro del contratto. Per ulteriori informazioni su come fornire l'input "seed" attraverso la sezione env, vedi La sezione env. È obbligatorio fornire entrambi i valori di inizializzazione per la cifratura. La crittografia ha esito negativo se solo una delle istanze fornite viene chiusa.

È possibile aggiungere un livello superiore di protezione e controllo della crittografia ai dati inattivi integrando con Hyper Protect Crypto Services. A partire da ibm-hyper-protect-container-runtime-1-0-s390x-11, è possibile utilizzare Hyper Protect Crypto Services per generare un valore casuale come terzo seme e avvolgerlo con la chiave root. La passphrase LUKS viene generata utilizzando tre seed - il seed nella partizione dei metadati e i due seed dal contratto. Per ulteriori informazioni, consultare Protezione dei dati.

Il seguente frammento è un esempio per la sezione dei volumi:

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

A partire dalla versione dell'immagine ibm-hyper-protect-container-runtime-1-0-s390x-9 HPCR, per le Hyper Protect Virtual Servers nuove istanze VPC, il volume di dati è suddiviso in due parti. La prima partizione ( 100Mib ) è riservata ai metadati interni; la seconda partizione rimane come volume di dati per il carico di lavoro. Solo i nuovi volumi sono partizionati e non puoi utilizzare il volume partizionato con una vecchia versione dell'immagine HPCR. Funziona anche il provisioning con un volume crittografato esistente. La differenza è che il volume esistente non viene partizionato ed è anche possibile tornare a un'immagine precedente con questo volume.

A partire da ibm-hyper-protect-container-runtime-1-0-s390x-12, il distributore e il fornitore possono utilizzare la funzione "rolling of seeds". Viene fornita un'opzione per ruotare o ruotare i semi per aumentare la postura di sicurezza o se il seme è compromesso. Quando il distributore o il fornitore o entrambi desiderano eseguire il rollio dei valori di inizializzazione, le informazioni sul valore di inizializzazione corrente devono essere specificate nel parametro previousSeed e le nuove informazioni sul valore di inizializzazione devono essere specificate nel parametro seed.

Il seguente frammento è un esempio per la sezione dei volumi:

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

A partire da ibm-hyper-protect-container-runtime-1-0-s390x-13, puoi collegare più volumi quando avvii l'istanza del server virtuale. I volumi collegati quando l'istanza è in esecuzione vengono ignorati.

Il seguente frammento è un esempio per la sezione dei volumi:

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 sottosezione 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 sottosezione env- volumes

Leggere la sottosezione workload - volumes della sezione workload prima di continuare con questa sezione. Come già menzionato, per la crittografia del disco automatico del volume di dati collegato, è necessario fornire due seed del cliente, uno nella sottosezione workload- volumes e l'altro nella sottosezione env- volumes. I semi possono essere qualsiasi testo casuale di vostra scelta.

Vedi il seguente esempio della sottosezione env- volumes:

volumes:
  test:
    seed: "seed_value_with_minimum_15_characters"

Quando si utilizza la funzione "rolling of seeds", è possibile utilizzare il seguente frammento come esempio:

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

Quando si utilizzano più volumi, il distributore deve verificare che i volumi vengano creati in anticipo e specificare anche l'ID volume nel file del contratto. Altrimenti, è necessario specificare il nome del volume e il volume deve essere creato con lo stesso nome. Se non vengono specificati entrambi, il tasto del volume viene considerato come nome del volume e il volume deve essere creato con lo stesso nome durante o prima della creazione dell'istanza del server virtuale. Il frammento di codice seguente ne è un esempio:

 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"

Dove:

• Nome volume: è il nome specificato quando si è creato il volume sul VPC.
• ID volume: è l'ID volume generato dal sistema del volume creato.
• Chiave volume: è il nome volume univoco per ogni volume.

Il tasto del volume deve essere lo stesso del tasto nella sottosezione del carico di lavoro - volumi.

Come detto, puoi eseguire l'integrazione con Hyper Protect Crypto Services per generare un terzo seed e includerlo nella tua chiave root. Vedi il seguente esempio. Per ulteriori informazioni, consultare Protezione dei dati.

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

sottosezione signingKey

Per ulteriori informazioni su come utilizzare signingKey, vedere Firma del contratto.

sottosezione env

• Se i descrittori pod vengono utilizzati nella sezione workload:

  Consultare l'esempio relativo al formato del modello nella sottosezione play.

• Se viene utilizzato un file di composizione docker nella sezione workload:

  Se il file docker compose ha una sezione di ambiente, puoi utilizzare il seguente frammento come esempio:

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

  Quando il file compose del docker ha una sezione environment, come mostrato nell'esempio precedente, è possibile passare i valori nella sezione env del deployer. Il seguente esempio mostra come specificare i valori per le variabili env:

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

Download del certificato di cifratura ed estrazione della chiave pubblica

1. Scarica il certificato. La tabella seguente riporta le date di scadenza dei certificati di crittografia e le date di dismissione/obsolescenza delle immagini in base alla versione dell'immagine.

Nota

• Deprecato- È possibile utilizzare l'immagine per creare un'istanza dalla CLI IBM Cloud. Lo stato deprecato può scoraggiare l'uso dell'immagine prima che il suo stato cambi in obsoleto. Il catalogo immagini mantiene sempre le due versioni più recenti dell'immagine: n e n-1. Quando è disponibile una nuova versione ( n+1 ), il sistema depreca la versione più vecchia ( n-1 ).
• Obsoleto: Dopo la scadenza del certificato associato all'immagine, l'immagine non è più disponibile per il provisioning di un'istanza.
• Scaricare sempre i certificati di crittografia corrispondenti all'immagine e crittografare i contratti.

Per controllare lo stato obsoleto o obsoleto dell'immagine, puoi anche utilizzare il comando IBM Cloud image list.

Puoi fare riferimento alla documentazione per il comando di elenco immagini per ottenere lo stato dell'immagine.

2. Convalidare il certificato di crittografia seguendo le istruzioni nell'argomento Convalida del certificato di crittografia del contratto.

Creazione della sezione workload crittografata di un contratto

Il valore di qualsiasi sezione in un contratto può essere testo semplice o crittografato. Completare i seguenti passaggi su un sistema Ubuntu per crittografare la sezione del carico di lavoro utilizzata in un contratto:

1. Creare il file docker-compose.yaml in base ai requisiti del carico di lavoro. Ad esempio,

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

   Per ulteriori informazioni, vedi Panoramica di Docker Compose.

2. Creare la sezione del carico di lavoro del contratto ed aggiungerne il contenuto al file workload.yaml.

   Di seguito è riportato un esempio di ​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. Esportare il percorso completo del file 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. Utilizza il seguente comando per creare una password casuale. Il contratto viene crittografato tramite AES simmetrico con una password casuale.

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

5. A partire da OpenSSL 3.0, il sottocomando OpenSSL rsautl è deprecato e viene sostituito dal sottocomando pkeyutl. Utilizzare uno dei seguenti comandi per criptare la password con ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt:

   • Utilizzo di rsautl (deprecato):

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

   • Utilizzando pkeyutl (consigliato):

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

6. Utilizzare il seguente comando per codificare il file workload.yaml con una password casuale:

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

7. Utilizzare il seguente comando per ottenere la sezione crittografata del contratto:

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

8. Ottenere l'output dal passo 7 e aggiungerlo al file user-data.yaml.

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

   Il prefisso hyper-protect-basic è obbligatorio.

Creazione della sezione env crittografata di un contratto

Completare i seguenti passaggi su un sistema Ubuntu per crittografare la sezione dell' env e utilizzata in un contratto:

1. Creare la env sezione del contratto e aggiungere il contenuto nel file env.yaml.

   Di seguito è riportato un esempio di 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. Esportare il percorso completo del file 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. Utilizza il seguente comando per generare una password casuale:

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

4. A partire da OpenSSL 3.0, il sottocomando OpenSSL rsautl è deprecato e viene sostituito dal sottocomando pkeyutl. Utilizzare uno dei seguenti comandi per criptare la password con ibm-hyper-protect-container-runtime-1-0-s390x-29-encrypt.crt:

   • rsautl (deprecato):

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

   • pkeyutl (consigliato):

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

5. Utilizzare il seguente comando per codificare env.yaml con una password casuale:

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

6. Utilizzare il seguente comando per ottenere la sezione crittografata del contratto:

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

7. Per crittografare la sezione del carico di lavoro, vedi Creazione della sezione workload crittografata di un contratto.

8. Ottenere l'output dal passo 6 e aggiungerlo al file user-data.yaml.

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

Registri di avviso di scadenza dei certificati di crittografia e attestazione

HPVS registra messaggi di avviso al servizio di registrazione configurato sui certificati di crittografia e di attestazione scaduti o in scadenza.

Il calendario delle notifiche è il seguente:

• 30 giorni prima della scadenza: Ogni 24 ore viene generato un messaggio di avviso che informa che il certificato scadrà tra un mese.

  Esempio:

  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 giorni prima della scadenza: I messaggi di avviso vengono registrati ogni 12 ore all'avvicinarsi della data di scadenza, evidenziando la necessità di intervenire.

  Esempio:

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

• Dopo la scadenza del certificato: Se il certificato è scaduto, HPVS registra messaggi di avviso ogni 4 ore fino all'aggiornamento dell'immagine HPVS.

  Esempio:

  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. Ottieni i dettagli della tua istanza di registrazione

È possibile configurare la registrazione con IBM Log Analysis o un backend syslog generico. Questo esempio utilizza IBM Log Analysis. Puoi scegliere tra diversi piani. Per capire come ottenere i dettagli richiesti, come il nome host e la chiave di ingestione, vedere Logging for Hyper Protect Virtual Servers per VPC.

2. Crea una sezione env

Assicurati di non perdere il simbolo del tubo '|' se stai usando un contratto di testo normale. Non è richiesto se si prevede di crittografare la sezione.

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

3. Preparazione del file docker-compose

Supponendo che tu abbia i dettagli di registrazione, trova un semplice file docker compose. L'esempio seguente ha un contenitore pubblico NGINX. Creare un sito docker-compose.yaml utilizzando l'esempio.

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

4. Ottieni la versione base64-encoded del file docker - compose

tar -czvf compose.tgz docker-compose.yaml

base64 -i compose.tgz > compose.b64

5. Crea la sezione di composizione con essa

  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. Popolare la sezione del carico di lavoro

Assicurati di non perdere il simbolo del tubo (|) se stai usando un contratto in testo normale.

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. Il tuo semplice contratto è 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==