Génération d'images

Vous pouvez générer vos images de plusieurs manières, y compris avec les services IBM Cloud suivants.

IBM Cloud Code Engine

Code Engine prend en charge la génération d'images à partir d'un Dockerfile et de modules de générations natifs cloud et insère automatiquement les images vers IBM Cloud® Container Registry. Pour plus d'informations, voir Planification de votre génération.

Pipelines Tekton

Le service Continuous Delivery inclut plusieurs tâches Tekton que vous pouvez référencez dans vos pipelines pour créer des images. Pour plus d'informations, voir Pipelines de Tekton.

Déploiement de conteneurs à partir d'un flux d'images existant dans le registre interne

Vous pouvez déployer une application à partir d'un flux d'images existant que votre administrateur de cluster a configuré dans le registre interne de votre cluster Red Hat OpenShift. Par exemple, votre administrateur de cluster peut avoir configuré le flux d'images pour importer une image à partir d'un registre privé externe, tel qu'IBM Cloud Container Registry.

Déploiement de conteneurs à partir d'une image IBM Cloud Container Registry vers le projet default Red Hat OpenShift

Vous pouvez déployer dans votre cluster des conteneurs depuis une image fournie par IBM ou depuis une image privée stockée dans votre espace de noms IBM Cloud Container Registry. Pour plus d'informations sur la façon dont votre cluster accède aux images de registre, voir Comment autoriser votre cluster à extraire des images d'IBM Cloud Container Registry.

Avant de commencer :

1. Configurez un espace de noms dans IBM Cloud Container Registry et envoyez des images dans cet espace de noms.

2. Créez un cluster.

3. Accédez à votre cluster Red Hat OpenShift.

4. Créez le fichier <deployment>.yaml de configuration de déploiement.

5. Définissez le déploiement et l'image à utiliser à partir de votre projet dans 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>

   Attribuez un nom à votre déploiement.

   <number_of_replicas>

   Entrez le nombre de pods de réplique créés par le déploiement.

   app: <app_name>

   Utilisez le nom de votre application sous forme de libellé pour le conteneur.

   name: <app_name>

   Attribuez un nom à votre conteneur, par exemple, le nom de votre libellé app.

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

   Remplacez les variables d'URL de l'image par les informations correspondant à votre image :

   region>: Le nœud final d'API IBM Cloud Container Registry régional pour le domaine de registre. Afin de répertorier le domaine pour la région à laquelle vous êtes connecté, exécutez la commande ibmcloud cr api.

   namespace>: L'espace de nom du registre. Pour obtenir des informations sur votre espace de noms, exécutez la commande ibmcloud cr namespace-list.

   image>:tag>: L'image et la balise que vous souhaitez utiliser pour votre conteneur. Pour répertorier les images disponibles dans votre espace de noms de registre, exécutez la commande ibmcloud cr images.

6. Créez le déploiement dans votre cluster.

   oc apply -f <deployment>.yaml
   

Déploiement de conteneurs à partir d'une image chiffrée

Déployez des conteneurs à partir d'une image chiffrée sur votre cluster en utilisant le module complémentaire de cluster Image Key Synchronizer.

Dans les clusters qui exécutent Red Hat OpenShift 4.5 ou une version ultérieure, le moteur d'exécution des conteneurs CRI-O prend en charge l'utilisation d'images de conteneurs cryptées. Les images de conteneur chiffrées sont des images OCI (Open Container Initiative) qui contiennent des contenus de couche chiffrée. Au lieu de sécuriser une image pour des développeurs individuels, par exemple, un développeur utilisant des secrets d'extraction d'image pour extraire des images d'un registre, vous pouvez activer le chiffrement d'image pour un cluster spécifique. Ainsi, vous pouvez être certain que les images chiffrées sont exécutées uniquement dans les clusters qui comportent la clé de déchiffrement d'image.

Pour exécuter une application à l'aide d'une image chiffrée, vous devez partager la clé de déchiffrement de l'image avec l'environnement d'exécution de conteneur sur les noeuds worker du cluster. Lorsque vous activez le module complémentaire Image Key Synchronizer dans le cluster, l'ensemble de démons du synchroniseur est déployé dans le projet image-key-synchronizer. Vous pouvez ensuite créer des secrets Kubernetes qui contiennent les clés de déchiffrement d'image dans ce projet. Le module complémentaire ajoute les clés dans un répertoire spécifique sur les noeuds worker dans lequel l'environnement d'exécution de conteneur peut accéder aux clés et les utiliser pour déchiffrer les images de conteneur. Notez que le module complémentaire Image Key Synchronizer prend également en charge les clés privées qui sont initialement encapsulées par une clé racine stockée dans une instance IBM® Key Protect.

Avant de commencer

1. Téléchargez et installez les clients CLI pour les outils open source suivants :

   • OpenSSL, pour générer une paire de clés RSA.
   • Docker Engine Pour extraire localement des images d'un registre d'images.
   • Skopeo, pour chiffrer les images de conteneur OCI.

2. Accédez à votre cluster Red Hat OpenShift.

3. Facultatif : lorsque vous créez une paire de clés publique et privée pour le chiffrement d'image, vous pouvez fournir la clé privée directement dans un secret, ou bien d'abord encapsuler la clé privée à l'aide d'une clé racine Key Protect ou d'un service de gestion de clés (KMS). Pour préparer l'encapsulation de la clé privée :

   1. Installez le plug-in d'interface de ligne de commande Key Protect.

   2. Créez une instance de service Key Protect.

   3. Créez une clé racine Key Protect.

   4. Obtenez les valeurs suivantes pour votre instance Key Protect :

      • L'ID d'instance de service.
      • La clé d'API de l'ID d'instance de service.
      • L'URL de noeud final de service.

   5. Créez un secret Kubernetes nommé keyprotect-config qui contient les valeurs que vous avez extraites. Le module complémentaire Image Key Synchronizer utilise les variables d'environnement de ce secret pour s'authentifier auprès de votre instance 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>"
            }
      

Pour déployer des conteneurs qui utilisent des images chiffrées :

1. Activez le module complémentaire Image Key Synchronizer.

   ibmcloud oc cluster addon enable image-key-synchronizer -c <cluster_name_or_ID>
   

2. Vérifiez que le jeu de démons addon-image-key-synchronizer a été créé avec succès dans le projet image-key-synchronizer de votre cluster.

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

3. Utilisez openssl pour générer une paire de clés RSA publique et privée.

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

4. Fournissez la clé privée directement dans un secret, ou bien d'abord encapsuler la clé privée à l'aide d'une clé racine à partir d'un service de gestion de clés (KMS), tel que Key Protect. Une fois que vous avez créé le secret dans le projet image-key-synchronizer, le module complémentaire Image Key Synchronizer copie automatiquement la clé privée dans le répertoire /etc/crio/keys/synced sur vos noeuds worker.

   • Pour fournir la clé privée directement : sauvegardez la clé privée en tan que secret Kubernetes dans le projet image-key-synchronizer.

     oc create -n image-key-synchronizer secret generic --type=key --from-file=myprivatekey.pem <secret_name>
     

   • Pour encapsuler la clé privée à l'aide d'une clé racine Key Protect :

     1. Codez votre clé privée en base64 et copiez la sortie.

        cat myprivatekey.pem | base64
        

     2. Utilisez le plug-in d'interface de ligne de commande Key Protect pour encapsuler la clé privée codée en base64 avec votre clé racine. Dans la sortie, copiez le texte chiffré de la clé privée encapsulée.

        ibmcloud kp key wrap <root_key_ID> -p <base64_encoded_private_key>
        

     3. Sauvegardez la clé privée encapsulée en tant que secret Kubernetes dans le projet image-key-synchronizer.

        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. Créez le secret.

        oc apply -n image-key-synchronizer -f <secret_name>.yaml
        

5. Utilisez docker pour extraire localement une image OCI. Remplacez <source_image> par le référentiel de l'image et <tag> par la balise de l'image que vous souhaitez utiliser, telle que latest.

   docker pull <source_image>:<tag>
   

6. Utilisez skopeo pour chiffrer l'image locale. Cette commande copie l'image OCI que vous avez extraite précédemment, utilise votre clé publique pour la chiffrer et sauvegarde l'image ainsi chiffrée dans un autre fichier local. Envisagez de nommer l'image chiffrée <source_image>_encrypted pour une identification facile.

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

7. Facultatif : pour vérifier localement que l'image est chiffrée, vous pouvez essayer de la déchiffrer avec une clé incorrecte.

   1. Générez une nouvelle clé privée.

      openssl genrsa --out wrongkey.pem 1024
      

   2. Essayez d'utiliser cette nouvelle clé pour déchiffrer l'image. La commande de déchiffrement échoue car la clé privée incorrecte a été spécifiée.

      skopeo copy --decryption-key ./wrongkey.pem <source_image>_encrypted:<tag> <source_image>_decrypted:<tag>
      

8. Facultatif : Envoyez l'image chiffrée à IBM Cloud Container Registry, qui prend en charge les images OCI chiffrées.

9. Spécifiez l'image chiffrée dans votre déploiement d'application. Par exemple, si vous avez inséré l'image chiffrée dans IBM Cloud Container Registry, vous pouvez suivre l'exemple dans le déploiement de conteneurs à partir d'une image IBM Cloud Container Registry vers le projet default Red Hat OpenShift. Lorsque vous créez le déploiement dans votre cluster, l'environnement d'exécution de conteneur utilise la clé de déchiffrement privée dans le répertoire /etc/crio/keys/synced pour déchiffrer l'image avant de l'exécuter.

10. Pour les autres images que vous souhaitez chiffrer, vous pouvez utiliser la même clé publique pour les chiffrer à l'aide de Skopeo ou vous pouvez répéter ces étapes pour utiliser une autre paire de clés publique et privée.

Si vous décidez par la suite de désactiver le module complémentaire, le jeu de démons addon-image-key-synchronizer est supprimé, mais le projet image-key-synchronizer et tous les secrets que vous avez créés dans ce projet ne sont pas supprimés, et le moteur d'exécution du conteneur peut toujours utiliser les secrets pour exécuter des images cryptées. Si vous souhaitez également retirer les clés de vos noeuds worker, vous devez supprimer les secrets correspondants du projet image-key-synchronizer avant de désactiver le module complémentaire.

Pour obtenir la liste des modifications apportées à chaque version du module complémentaire Image Key Synchronizer, consultez le journal des modifications du module complémentaire Image Key Synchronizer à l'adresse IBM Cloud.

Référencement du secret d'extraction d'image dans votre déploiement de pod

Si l'administrateur de cluster n'a pas stocké le secret d'image dans le compte de service Kubernetes, tous les déploiements qui ne spécifiaient pas de compte de service ne peuvent pas utiliser le secret d'extraction d'image pour déployer des conteneurs. A la place, vous pouvez définir un secret d'extraction d'image dans votre déploiement de pod. Lorsque vous faites référence au secret d'extraction d'image dans un déploiement de pod, le secret d'extraction de l'image est valide pour ce pod uniquement et ne peut pas être partagé entre des pods dans le projet Red Hat OpenShift.

Avant de commencer

• Créez un secret d'extraction d'image pour accéder aux images d'autres registres ou d'autres projets Red Hat OpenShift que default.
• Accédez à votre cluster Red Hat OpenShift.

Pour vous faire réfrence au secret d'extraction d'image dans votre déploiement de pod.

1. Créez un fichier de configuration de pod nommé mypod.yaml.

2. Définissez le pod et le secret d'extraction d'image pour accéder aux images dans IBM Cloud Container Registry.

   Pour accéder à une image privée,

   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>
   

   Pour accéder à une image publique 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>

   Nom du conteneur à déployer dans votre cluster. namespace_name>: Espace de noms de registre sous lequel l'image est stockée. Pour répertorier les espaces de noms disponibles, exécutez la commande ibmcloud cr namespace-list. image_name>: Nom de l'image à utiliser. Pour répertorier les images disponibles dans un compte IBM Cloud, exécutez la commande ibmcloud cr image-list. tag>: Version de l'image que vous désirez utiliser. Si aucune balise n'est spécifiée, l'image balisée est la dernière utilisée par défaut. <secret_name>: Nom du secret d'extraction d'image que vous avez créé précédemment.

3. Sauvegardez vos modifications.

4. Créez le déploiement dans votre cluster.

   oc apply -f mypod.yaml
   

Envoi d'images à IBM Cloud Container Registry

Après que l'administrateur de cluster a configuré un registre d'images avec IBM Cloud Container Registry, vous pouvez stocker et partager en toute sécurité des images Docker avec d'autres utilisateurs en ajoutant des images à votre espace de noms.

Par exemple, vous pouvez extraire une image de n'importe quelle source de registre privé ou public, puis la baliser pour une utilisation ultérieure dans IBM Cloud Container Registry. Ou bien, vous pouvez envoyer à votre espace de noms une image Docker avec laquelle vous travaillez afin que les autres utilisateurs puissent accéder à cette image. Pour commencer, voir Ajout d'images à votre espace de noms.

Gestion de la sécurité des images dans IBM Cloud Container Registry avec Vulnerability Advisor

Vulnerability Advisor vérifie le statut de sécurité des images de conteneur qui sont fournies par IBM ou des tiers ou qui sont ajoutées à l'espace de noms IBM Cloud Container Registry de votre organisation.

Lorsque vous ajoutez une image à un espace de noms, cette image est automatiquement analysée par Vulnerability Advisor pour détecter des problèmes de sécurité et des vulnérabilités potentielles. Si des problèmes de sécurité sont identifiés, des instructions vous sont soumises afin de vous aider à résoudre la vulnérabilité signalée. Pour commencer, voir Gestion de la sécurité des images avec Vulnerability Advisor.

Configuration de contenu sécurisé pour des images de conteneur

Vous pouvez générer des conteneurs à partir d'images sécurisées qui sont signées et stockées dans IBM Cloud Container Registry et empêcher les déploiements à partir d'images non signées ou vulnérables.

1. Signez les images pour le contenu sécurisé. Après avoir défini la fonction de confiance (trust) pour vos images, vous pouvez gérer du contenu sécurisé et les signataires peuvent envoyer des images par commande push dans votre registre.
2. Pour imposer une règle stipulant que seules des images signées peuvent être utilisées pour générer des conteneurs dans votre cluster, installez le projet Portieris open source.
3. Les utilisateurs de cluster peuvent déployer des applications qui sont générées à partir d'images sécurisées.
   1. Déployez l'espace de noms Kubernetes default.
   2. Effectuez un déploiement dans un autre espace de noms Kubernetes ou à partir d'une autre région ou d'un autre compte IBM Cloud.

Activation de la mise en application de la sécurité des images dans votre cluster

Lorsque vous activez la mise en application de la sécurité des images dans votre cluster, vous installez le projet Kubernetes Portieris open source. Vous pouvez ensuite créer des stratégies d'image pour empêcher les pods qui ne répondent pas aux règles, telles que les images non signées, de s'exécuter dans votre cluster.

Pour plus d'informations, voir la documentation de Portieris.

Images ayant fait l'objet d'une mutation : par défaut, Portieris utilise le contrôleur d'admission MutatingAdmissionWebhook pour effectuer une mutation sur votre image afin de faire référence à celle-ci par un résumé et non par une balise. Toutefois, il peut arriver qu'une technologie de déploiement rejette une image ayant fait l'objet d'une mutation Si tel est le cas, vous pouvez utiliser l’ option et la politique de mutation d’image pour modifier le comportement par défaut.