Creazione di immagini

Puoi creare le tue immagini in diversi modi, tra cui i seguenti IBM Cloud servizi.

IBM Cloud Code Engine

Code Engine supporta la creazione di immagini da un file Docker e da Cloud Native Buildpacks e il push automatico delle immagini su IBM Cloud® Container Registry. Per ulteriori informazioni, vedi Pianificazione della tua build.

Pipeline Tekton

Il servizio Continuous Delivery include diverse attività Tekton a cui puoi fare riferimento all'interno delle tue pipeline per creare immagini. Per ulteriori informazioni, vedi Pipeline Tekton.

Distribuzione dei contenitori da un flusso di immagini esistente nel registro interno

È possibile distribuire un'applicazione da uno stream di immagini esistente configurato dall'amministratore del cluster nel registro interno del cluster Red Hat OpenShift. Ad esempio, il tuo amministratore cluster potrebbe aver configurato il flusso di immagini per importare un'immagine da un registro privato esterno, come ad esempio IBM Cloud Container Registry.

Distribuzione di container da un'immagine IBM Cloud Container Registry al progetto default Red Hat OpenShift

Puoi distribuire i contenitori al tuo cluster da un'immagine pubblica fornita da IBM o da un'immagine privata memorizzata nel tuo spazio dei nomi IBM Cloud Container Registry. Per ulteriori informazioni sul modo in cui il tuo cluster accede alle immagini del registro, vedi Informazioni su come il tuo cluster è autorizzato a eseguire il pull di immagini da IBM Cloud Container Registry.

Prima di cominciare:

1. Configura uno spazio dei nomi in IBM Cloud Container Registry e inserisci le immagini in questo spazio dei nomi.

2. Crea un cluster.

3. Accedi al tuo cluster Red Hat OpenShift.

4. Creare un file di configurazione di distribuzione denominato “ <deployment>.yaml ”.

5. Definisci la distribuzione e l'immagine da utilizzare dal tuo progetto in IBM Cloud Container Registry.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: <deployment>
   spec:
     replicas: <number_of_replicas>
     selector:
       matchLabels:
         app: <app_name>
     template:
       metadata:
         labels:
           app: <app_name>
       spec:
         containers:
         - name: <app_name>
           image: <region>.icr.io/<project>/<image>:<tag>
   

   <deployment>

   Fornisci un nome alla tua distribuzione.

   <number_of_replicas>

   Immetti il numero di pod di replica creati dalla tua distribuzione.

   app: <app_name>

   Utilizza il nome della tua applicazione come etichetta per il contenitore.

   name: <app_name>

   Fornisci un nome per il tuo contenitore, ad esempio il nome dell'etichetta app.

   image: <region>.icr.io/project>/image>:tag>

   Sostituisci le variabili dell'URL dell'immagine con le informazioni relative alla tua immagine:

   region>: L'endpoint API regionale IBM Cloud Container Registry per il dominio di registro. Per elencare il dominio per la regione in cui hai effettuato l'accesso, esegui ibmcloud cr api.

   namespace>: Lo spazio dei nomi del registro. Per ottenere le informazioni sul tuo spazio dei nomi, esegui ibmcloud cr namespace-list.

   image>:tag>: L'immagine e il tag che desideri utilizzare per il tuo container. Per elencare le immagini disponibili nello spazio dei nomi del tuo registro, esegui ibmcloud cr images.

6. Crea la distribuzione nel tuo cluster.

   oc apply -f <deployment>.yaml
   

Distribuzione di contenitori da un'immagine crittografata

Distribuisci i contenitori da una immagine crittografata al tuo cluster utilizzando il componente aggiuntivo del cluster Image Key Synchronizer.

Nei cluster che eseguono Red Hat OpenShift 4.5 o successive, il runtime del contenitore CRI-O supporta l'utilizzo di immagini del contenitore crittografate. Le immagini del contenitore codificate sono immagini OCI (Open Container Initiative) che contengono contenuti di livello codificati. Invece di proteggere un'immagine per singoli sviluppatori, come uno sviluppatore che utilizza i segreti di pull dell'immagine per estrarre immagini da un registro, puoi abilitare la codifica dell'immagine per uno specifico cluster. In questo modo, puoi garantire che le immagini crittografate vengano eseguite solo nei cluster specifici che hanno la chiave di decrittografia dell'immagine.

Per eseguire un'applicazione utilizzando un'immagine crittografata, devi condividere la chiave per decrittografare l'immagine con il tempo di esecuzione del contenitore sui nodi di lavoro nel cluster. Quando si abilita il componente aggiuntivo Image Key Synchronizer nel proprio cluster, la serie di daemon del programma di sincronizzazione viene distribuita nel progetto image-key-synchronizer. Puoi quindi creare i segreti Kubernetes che contengono le chiavi di decodifica dell'immagine in quel progetto. Il componente aggiuntivo aggiunge le chiavi a una directory specifica sui nodi di lavoro in cui il runtime del contenitore può accedere e utilizzare le chiavi per decodificare le immagini del contenitore. Nota che il componente aggiuntivo Image Key Synchronizer supporta anche le chiavi private che vengono prima racchiuse da una chiave root memorizzata in un'istanza IBM® Key Protect.

Prima di iniziare

1. Scarica e installa i client CLI per i seguenti strumenti open source:

   • OpenSSL, per generare una coppia di chiavi RSA.
   • CLIDocker Engine, per eseguire localmente il pull delle immagini da un registro delle immagini.
   • Skopeo, per crittografare immagini del contenitore OCI.

2. Accedi al tuo cluster Red Hat OpenShift.

3. Facoltativo: quando crei una coppia di chiavi pubblica e privata per la crittografia dell'immagine, puoi fornire la chiave privata direttamente in un segreto o prima impacchettare la chiave privata utilizzando una chiave root Key Protect o un KMS (key management service). Per preparare il wrapping della chiave privata:

   1. Installa il plugin della CLI Key Protect.
   2. Crea un'istanza del servizio Key Protect.
   3. Crea una chiave root Key Protect.
   4. Ottieni i seguenti valori per la tua istanza Key Protect:
      • L'ID istanza del servizio.
      • La chiave dell'API per l'ID istanza del servizio.
      • L'endpoint del servizio URL.
   5. Crea un segreto Kubernetes denominato keyprotect-config che contiene i valori che hai richiamato. Il componente aggiuntivo Image Key Synchronizer utilizza le variabili d'ambiente in questo segreto per autenticarsi con la tua istanza Key Protect.

       apiVersion: v1
       kind: Secret
       metadata:
         name: keyprotect-config
         namespace: image-key-synchronizer
       type: Opaque
       stringData:
         config.json: |
             {
                 "keyprotect-url":"<service_endpoint>",
                 "instance-id": "<service_instance_ID>",
                 "apikey": "<service_instance_ID_API_key>"
             }
       ```
   

Per distribuire i contenitori che utilizzano immagini crittografate:

1. Aggiorna il plug-in " container-service " alla versione più recente.

   ibmcloud update && ibmcloud plugin update container-service
   

2. Abilitare il componente aggiuntivo Image Key Synchronizer.

   ibmcloud oc cluster addon enable image-key-synchronizer -c CLUSTER_NAME_OR_ID
   

3. Verificare che la serie di daemon addon-image-key-synchronizer sia stata creata correttamente nel progetto image-key-synchronizer nel cluster.

   oc get ds addon-image-key-synchronizer -n image-key-synchronizer
   

4. Utilizzare openssl per creare una coppia di chiavi RSA pubblica e privata.

   openssl genrsa -out myprivatekey.pem
   openssl rsa -in myprivatekey.pem -pubout -out mypubkey.pem
   

5. Fornisci la chiave privata direttamente in un segreto o per prima cosa impacchetta la chiave privata utilizzando una chiave root da un KMS (key management service), come Key Protect. Dopo aver creato il segreto nel progetto image-key-synchronizer, il componente aggiuntivo Image Key Synchronizer copia automaticamente la chiave privata nella directory /etc/crio/keys/synced sui tuoi nodi di lavoro.

   • Per fornire direttamente la chiave privata: salva la chiave privata come un segreto Kubernetes nel progetto image-key-synchronizer.

       oc create -n image-key-synchronizer secret generic --type=key --from-file=myprivatekey.pem <secret_name>
       ```
   - **Per impacchettare la chiave privata utilizzando una Key Protect**:
       1. Codifica la chiave privata in base64e copia l'output.
   
           ```sh {: pre}
           cat myprivatekey.pem | base64
           ```
       2. Utilizza il plug-in della CLI Key Protect per impacchettare la chiave privata base64-encoded con la tua chiave root. Nell'output, copia il testo crittografato della chiave privata impacchettata.
   
           ```sh {: pre}
           ibmcloud kp key wrap ROOT_KEY_ID -p BASE64_ENCODED_PRIVATE_KEY
           ```
       3. Salva la chiave privata impacchettata come un segreto Kubernetes nel progetto `image-key-synchronizer`.
   
           ```yaml {: pre}
           apiVersion: v1
           kind: Secret
           type: kp-key
           metadata:
             name: <secret_name>
             namespace: image-key-synchronizer
           stringData:
             rootkeyid: "<root_key_ID>"
             ciphertext: "<wrapped_private_key_cipertext>"
           ```
       4. Crea il segreto.
   
           ```sh {: pre}
           oc apply -n image-key-synchronizer -f <secret_name>.yaml
           ```
   

6. Utilizzare docker per estrarre localmente un'immagine OCI. Sostituisci <source_image> con il repository dell'immagine e <tag> con il tag dell'immagine che desideri utilizzare, ad esempio latest.

   docker pull <source_image>:<tag>
   

7. Utilizzare skopeo per codificare l'immagine locale. Questo comando copia l'immagine OCI che hai precedentemente estratto, utilizza la tua chiave pubblica per crittografare l'immagine e salva l'immagine crittografata in un file locale diverso. Considerare la possibilità di denominare l'immagine codificata <source_image>_encrypted per una facile identificazione.

   skopeo copy --encryption-key jwe:./mypubkey.pem <source_image>:<tag> <source_image>_encrypted:<tag>
   

8. Facoltativo: per verificare localmente che l'immagine sia crittografata, puoi provare a decrittografarla con una chiave non corretta.

   1. Genera una nuova chiave privata.

       openssl genrsa --out wrongkey.pem 1024
       ```
   2. Tentare di utilizzare questa nuova chiave per decodificare l'immagine. Il comando di decodifica ha esito negativo perché è stata specificata la chiave privata errata.
   
   ```sh {: pre}
       skopeo copy --decryption-key ./wrongkey.pem <source_image>_encrypted:<tag> <source_image>_decrypted:<tag>
       ```
   

9. Facoltativo: invia l'immagine crittografata a IBM Cloud Container Registry, che supporta le immagini OCI crittografate.

10. Specificare l'immagine crittografata nella distribuzione dell'app. Ad esempio, se hai eseguito il push dell'immagine crittografata a IBM Cloud Container Registry, puoi seguire l'esempio in Distribuzione dei contenitori da un'immagine IBM Cloud Container Registry al progetto default Red Hat OpenShift. Quando crei la distribuzione nel tuo cluster, il runtime del contenitore utilizza la chiave di decodifica privata nella directory /etc/crio/keys/synced per decodificare l'immagine prima di eseguirla.

11. Per tutte le immagini successive che vuoi codificare, puoi utilizzare la stessa chiave pubblica per codificare le immagini con Skopeoo ripetere questi passi per utilizzare una diversa coppia di chiavi pubblica e privata.

Se successivamente decidi di disabilitare il componente aggiuntivo, la serie di daemon addon-image-key-synchronizer viene rimossa, ma il progetto image-key-synchronizer e tutti i segreti che hai creato in quel progetto non vengono rimossi e il runtime del contenitore può ancora utilizzare i segreti per eseguire immagini crittografate. Se vuoi rimuovere le chiavi anche dai tuoi nodi di lavoro, devi eliminare i segreti corrispondenti dal progetto image-key-synchronizer prima di disabilitare il componente aggiuntivo.

Per l'elenco delle modifiche apportate a ciascuna versione dell'add-on Image Key Synchronizer, consultare il registro delle modifiche IBM Cloud dell'add-on Image Key Synchronizer.

Riferimento al segreto di pull dell'immagine nella tua distribuzione del pod

Se l'amministratore del cluster non ha memorizzato il segreto per il recupero delle immagini nell'account di servizio Kubernetes, tutte le distribuzioni che non specificano un account di servizio non potranno utilizzare il segreto per il recupero delle immagini per distribuire i container. Puoi invece definire un segreto di pull dell'immagine nella tua distribuzione del pod. Quando si fa riferimento al segreto di recupero dell'immagine in una distribuzione di pod, tale segreto è valido solo per quel pod e non può essere condiviso tra i pod del progetto Red Hat OpenShift.

Prima di iniziare

• Crea un segreto per il recupero delle immagini per accedere alle immagini presenti in altri registri o in progetti Red Hat OpenShift diversi da default.
• Accedi al tuo cluster Red Hat OpenShift.

Per fare riferimento al segreto "pull" dell'immagine nella distribuzione del tuo pod,

1. Crea un file di configurazione del pod denominato mypod.yaml.

2. Definisci il pod e il segreto di pull dell'immagine per l'accesso alle immagini in IBM Cloud Container Registry.

   Per accedere a un'immagine privata,

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     containers:
       - name: <container_name>
         image: <region>.icr.io/<namespace_name>/<image_name>:<tag>
     imagePullSecrets:
       - name: <secret_name>
   

   Per accedere a un'immagine pubblica su IBM Cloud,

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     containers:
       - name: <container_name>
         image: icr.io/<image_name>:<tag>
     imagePullSecrets:
       - name: <secret_name>
   

   container_name>

   Il nome del contenitore da distribuire al tuo cluster. namespace_name>: Lo spazio dei nomi del registro in cui è memorizzata l'immagine. Per elencare gli spazi dei nomi disponibili, esegui ibmcloud cr namespace-list. image_name>: Il nome dell'immagine da utilizzare. Per elencare le immagini disponibili in un account IBM Cloud, esegui ibmcloud cr image-list. tag>: La versione dell'immagine che desideri utilizzare. Se non viene specificato alcun tag, per impostazione predefinita viene utilizzata l'immagine contrassegnata con il tag più recente. <secret_name>: Il nome del segreto di recupero delle immagini che hai creato in precedenza.

3. Salva le tue modifiche.

4. Crea la distribuzione nel tuo cluster.

   oc apply -f mypod.yaml
   

Esecuzione del push di immagini a IBM Cloud Container Registry

Dopo che l'amministratore del cluster ha configurato un registro di immagini con IBM Cloud Container Registry, puoi archiviare e condividere in modo sicuro le immagini Docker con altri utenti aggiungendo le immagini al tuo spazio dei nomi.

Ad esempio, potresti eseguire il pull di un'immagine da qualsiasi origine di registro privato o pubblico e quindi contrassegnarla con una tag per un successivo utilizzo in IBM Cloud Container Registry. Potresti anche eseguire il push di un'immagine Docker con cui lavori al tuo spazio dei nomi in modo che altri utenti possano accedere ad essa. Per iniziare, vedi Aggiunta di immagini al tuo spazio dei nomi.

Gestione della sicurezza delle immagini in IBM Cloud Container Registry con Vulnerability Advisor

Vulnerability Advisor controlla lo stato di sicurezza delle immagini del contenitore fornite da IBM o da terze parti oppure aggiunte allo spazio dei nomi IBM Cloud Container Registry della tua organizzazione.

Quando aggiungi un'immagine a uno spazio dei nomi, il Vulnerability Advisor ne esegue automaticamente la scansione per rilevare problemi di sicurezza e potenziali vulnerabilità. Se si riscontrano dei problemi di sicurezza, vengono fornite le istruzioni per facilitare la correzione delle vulnerabilità segnalate. Per iniziare, vedi Gestione della sicurezza delle immagini con Vulnerability Advisor.

Configurazione dei contenuti attendibili per le immagini di contenitore

Puoi creare dei contenitori dalle immagini attendibili che sono firmate e memorizzate in IBM Cloud Container Registry e impedire le distribuzioni da immagini non firmate o vulnerabili.

1. Firma le immagini per i contenuti attendibili. Una volta configurata l'attendibilità delle tue immagini, puoi gestire i contenuti attendibili e i firmatari che possono inserire le immagini nel tuo registro.
2. Per applicare una politica in modo che solo le immagini firmate possano essere utilizzate per creare contenitori nel cluster, installa il progetto Portieris open source.
3. Gli utenti del cluster possono distribuire le applicazioni create da immagini attendibili.
   1. Distribuisci nello spazio dei nomi Kubernetes default.
   2. Distribuisci in uno spazio dei nomi Kubernetes diverso oppure da IBM Cloud una regione o da un account diversi.

Attivazione delle misure di sicurezza relative alle immagini nel proprio cluster

Quando si abilita l'applicazione della sicurezza delle immagini nel cluster, si installa il progetto open PortierisKubernetes source. È quindi possibile creare criteri relativi alle immagini per impedire che i pod non conformi a tali criteri, come ad esempio le immagini non firmate, vengano eseguiti nel proprio cluster.

Per ulteriori informazioni, vedi la documentazione diPortieris.

Immagini modificate: per impostazione predefinita, Portieris utilizza il controller MutatingAdmissionWebhook di ammissione per modificare l'immagine in modo che faccia riferimento all'immagine tramite un digest anziché un tag. Tuttavia, è possibile che si disponga di una tecnologia di distribuzione che rifiuta un'immagine mutata. In tal caso, è possibile utilizzare l'opzione di mutazione immagine e la politica per modificare il comportamento predefinito.