Qu'est-ce qu'un conteneur confidentiel?

Un conteneur confidentiel fournit un environnement d'exécution sécurisé pour les charges de travail sensibles, tout en vous permettant de continuer à travailler dans le cadre des flux de travail existants.

La mise en œuvre des conteneurs confidentiels sur le site IBM Cloud s'appuie sur les pods de pairs pour étendre la fonctionnalité des pods Red Hat OpenShift dans un VSI distinct du nœud de travail. Cette extension crée un environnement d'exécution fiable au-delà des Kubernetes et OpenShift traditionnels.

En savoir plus :

• Passez en revue les raisons pour lesquelles vous pourriez utiliser des conteneurs confidentiels.
• Consultez le site Questions fréquemment posées pour les conteneurs confidentiels.

Prérequis

• Lorsque vous créez ou choisissez le cluster Red Hat OpenShift on IBM Cloud à utiliser, le cluster doit répondre aux exigences suivantes :

  • Le cluster doit se trouver dans une région qui prend en charge les instances de serveur virtuel(VSI)TDX.
  • Le cluster doit disposer d'une interface publique ou vous pouvez vous connecter à son environnement via un VPN.
  • Pour permettre au cluster de communiquer avec tout VSI créé avec des conteneurs confidentiels, il faut créer un groupe de sécurité nommé kube-CLUSTER_ID pour le cluster.

• Si nécessaire, activer OperatorHub. Il arrive que OperatorHub soit désactivé dans un cluster pour des raisons de sécurité.

Étape 1 : Installation de l'opérateur

Installez l'opérateur OpenShift Sandboxed Containers pour gérer le cycle de vie des conteneurs confidentiels dans les clusters.

1. Ouvrez le tableau de bord du cluster.

2. Cliquez sur OpenShift web console > Operators > OperatorHub.

3. Recherchez OpenShift sandboxed containers Operator et cliquez sur la tuile.

4. Cliquez sur Installer pour obtenir la version stable et supportée de OpenShift Sandboxed Containers Operator, version 1.10.3. Consultez le site Red Hat 's Operator Update Information Checker pour connaître les versions prises en charge de OpenShift.

5. Dans la fenêtre Installer l'opérateur, vous pouvez conserver les sélections par défaut et cliquer sur Installer.

6. Attendez la fin de l'installation. Cliquez sur le lien View installed Operators in Namespace openshift-sandboxed-containers-operator et attendez que le statut soit Succeeded. Pendant que vous attendez, vous pouvez effectuer l'étape suivante pour configurer le CLI.

Étape 2 : Configuration du CLI

Avant de commencer, vous pouvez soit suivre ces étapes pour configurer le CLI, soit utiliser l'interpréteur de commandes IBM Cloud pour exécuter des commandes.

1. Installer la ligne de commande IBM Cloud.

2. Installez les outils ks et oc CLI.

3. Connectez-vous à l'interface de ligne de commande d'IBM Cloud.

   ibmcloud login --apikey API_KEY -g RESOURCE_GROUP
   

4. Dressez la liste des clusters du compte et copiez l'ID du cluster que vous souhaitez utiliser pour l'étape suivante.

   ibmcloud ks cluster ls
   

5. Exécutez la commande config.

   ibmcloud ks cluster config --cluster CLUSTER_ID --admin --endpoint link
   

   Dans votre répertoire personnel, un dossier .kube est créé et des informations y sont stockées pour communiquer avec ce cluster.

6. Confirmez que les commandes oc s'exécutent correctement en affichant les détails des nœuds de travail dans le cluster.

   oc get nodes
   

7. Définissez l'espace de noms du projet afin de ne pas devoir inclure l'espace de noms dans les commandes ultérieures.

   oc project openshift-sandboxed-containers-operator
   

8. Facultatif : Explorez l'espace de noms.

   oc get all
   

   Par exemple, dans la liste des pods, le gestionnaire de contrôleur nommé pod/controller-manager-<id> gère les microservices au sein de l'opérateur.

9. Installez l'outil CLI is.

Étape 3 : Importation de l'image du pod pair

L'opérateur OpenShift Sandboxed Containers lance un système d'exploitation spécial à l'intérieur du pod pair qui doit être importé dans votre compte IBM Cloud. Ce système d'exploitation est nécessaire pour déployer une charge de travail dans un conteneur confidentiel.

L'image du pod pair contient un système d'exploitation complet Red Hat Enterprise Linux (RHEL) 9.6 avec le logiciel nécessaire pour instancier un conteneur dans une machine virtuelle confidentielle (CVM).

Toutes les configurations et tous les paquets installés dans le système d'exploitation conservent les valeurs par défaut de l' Red Hat. Cependant, les VSI de l' IBM Cloud doivent cloud init fonctionner. Dans les scripts, cloud init ne peut pas être désinstallé lorsqu'il a fini de construire le site podvm, ce qui constitue une différence essentielle par rapport à son image source.

Avant de commencer :

Valider la compatibilité des versions. L'image est prise en charge pour les versions suivantes.

• OpenShift Conteneurs en bac à sable Version de l'opérateur 1.10.3
• OpenShift versions 4.19, 4.18, 4.17, et 4.16 clusters

Pour importer l'image d'un pod homologue :

1. Exécutez la image-create commande.

   # Note IMAGE_NAME is a placeholder variable. Image names do not support capitalization.
   ibmcloud is image-create "IMAGE_NAME" --file cos://us-south/podvm-image/rhel9-podvm-latest.qcow2  --os-name red-9-amd64
   

2. Ouvrez les images informatiques.

3. Cliquez sur l'icône Créer +, choisissez une région disposant de VSI compatibles TDX, puis remplissez les champs obligatoires.

   a. Pour Source de l'image, sélectionnez Cloud Object Storage.

   b. Sélectionnez l'onglet Localiser par fichier image URL et pour l'image URL, entrez cos://us-south/podvm-image/rhel9-podvm-latest.qcow2.

   c. Pour le système d'exploitation, sélectionnez Red Hat Enterprise Linux > red-9-amd64.

   d. Facultatif : Pour créer ultérieurement un autre conteneur confidentiel à partir de l'API avec les mêmes détails, cliquez sur le bouton Obtenir un exemple d'appel API et copiez la commande Curl.

   e. Cliquez sur Créer une image personnalisée.

4. Lorsque l'image est ajoutée à la liste des images, cliquez sur son nom et sélectionnez l'onglet ID. Ensuite, notez l 'ID de l'image pour pouvoir l'utiliser plus tard.

5. Attendez que le statut de l'image passe à Disponible.

   ibmcloud is image IMAGE_NAME
   

6. Répétez ces étapes lorsqu'une nouvelle version de l'image est disponible.

Étape 4 : Création d'une clé API ou d'un profil de confiance

Les conteneurs confidentiels nécessitent un justificatif d'identité pour instancier le pod homologue via kata-remote lorsqu'une charge de travail sécurisée est lancée. Cet identifiant doit être une clé API valide ou un profil de confiance ayant les permissions de créer une ISV dans votre compte.

Si vous testez des conteneurs confidentiels, vous pouvez utiliser une clé API. Si vous utilisez Secrets Manager, vous devez configurer un profil de confiance.

• Clé API depuis l'interface utilisateur

  1. Dans le tableau de bord IBM Cloud, cliquez sur Gérer > Accès (IAM ) > Clés API.

  2. Cliquez sur Créer.

  3. Conservez cette clé en lieu sûr, car elle ne pourra pas être récupérée ultérieurement à partir de cette page.

• Clé API depuis l'interface CLI.

  Exécutez la commande suivante et enregistrez le résultat.

  ibmcloud iam api-key-create KEY_NAME
  

• Profil sécurisé

  1. Ouvrez le tableau de bord des profils de confiance.

  2. Créez un profil de confiance et accordez-lui les autorisations nécessaires pour créer des serveurs virtuels à partir de OpenShift.

     a. Créez un profil sécurisé.

     ibmcloud iam trusted-profile-create <NAME> [--description <DESCRIPTION>]
     

     b. Autoriser les ressources de openshift-sandboxed-containers-operator à utiliser le profil de confiance.

     ibmcloud iam trusted-profile-rule-create PROFILE_NAME_OR_ID --name RULE_NAME --type Profile-CR --conditions claim:namespace,operator:EQUALS,value:openshift-sandboxed-containers-operator --cr-type ROKS_SA
     

     c. Autoriser l'accès aux services d'infrastructure VPC (is).

     Pour autoriser l'accès à toutes les ressources du compte :

     ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile>  --roles Editor,Writer --service-name is
     

     Pour autoriser l'accès à un groupe de ressources spécifique :

     ibmcloud iam trusted-profile-policy-create <NAME or ID of the trusted profile> --roles Viewer [--resource-group-id <resource group>]
     

Étape 5 : Création d'une clé SSH (facultatif)

Dans les clusters de test, il peut être utile d'avoir une clé SSH prête à l'emploi pour déterminer pourquoi quelque chose ne démarre pas et pour consulter les journaux. Dans les clusters de production, il se peut que vous ne souhaitiez pas activer la fonctionnalité SSH.

1. Cliquez sur Infrastructure > Compute > SSH Keys.

2. Créez une clé SSH et notez l'ID de la clé SSH.

Étape 6 : Configuration des conteneurs confidentiels

Une fois l'opérateur installé, créez ConfigMaps pour permettre à Kata de gérer les charges de travail du compte IBM Cloud.

1. Créez un répertoire pour stocker les fichiers.

   mkdir <directory-name>
   

2. Passez au répertoire.

   cd <directory-name>
   

3. Copiez les variables d'environnement suivantes pour la clé API, l'ID du profil de confiance, le nom du cluster, l'ID de l'image PodVM, l'ID de la clé SSH et l'ID VPC (facultatif).

   Facultatif : vous pouvez les enregistrer dans un script Shell dans le nouveau répertoire afin de les redéfinir ultérieurement. Exemple:<directory-name>/env-vars.sh

   a. Recueillez les valeurs des variables suivantes et mettez-les à jour dans le script.

   • Pour le site CLUSTER_NAME, ouvrez les détails du cluster dans la liste des clusters et copiez le nom.
   • Facultatif : Pour le site VPC_ID, dans la section Détails du cluster de la même page, vous pouvez cliquer sur le nom du VPC pour ouvrir les détails du VPC et copier le champ VPC ID.
   • Pour PODVM_IMAGE_ID, utilisez l'ID d'image que vous avez enregistré pour l'image du pod homologue.
   • Si vous utilisez une clé API, vous pouvez supprimer la ligne IBMCLOUD_TRUSTED_PROFILE_ID.
   • Si vous utilisez un profil de confiance, vous pouvez supprimer la ligne IBMCLOUD_API_KEY.
   • Si vous n'avez pas défini de clé SSH, vous pouvez supprimer la ligne SSH_KEY_ID.

   export IBMCLOUD_API_KEY=<your API key>
   export IBMCLOUD_TRUSTED_PROFILE_ID="<your Trusted Profile ID>"
   export CLUSTER_NAME=<cluster-name-region-flavor>
   export PODVM_IMAGE_ID=<PodVM image ID provided by IBM or a custom-built image>
   export SSH_KEY_ID=<SSH key ID to be used by the peer pod VSI>
   export VPC_ID=<Optional: the VPC that your Openshift cluster is in>
   

   b. Si vous avez enregistré les variables dans un script Shell, exécutez-le. Exemple :

   sh env-vars.sh
   

4. Exécutez la commande pour créer le fichier feature-gates.yaml ConfigMap.

   cat > feature-gates.yaml <<EOF
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: osc-feature-gates
     namespace: openshift-sandboxed-containers-operator
   data:
     deploymentMode: "DaemonSetFallback" # or DaemonSet to force it
     confidential: "true"
     layeredImageDeployment: "false"
   EOF
   

5. Appliquer le site ConfigMap.

   oc apply -f feature-gates.yaml
   

6. Exécutez la commande pour créer le site peer-pods-secret.yaml. Supprimez toutes les variables d'environnement facultatives de la section stringData dont vous n'avez pas besoin.

   cat > peer-pods-secret.yaml <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: peer-pods-secret
     namespace: openshift-sandboxed-containers-operator
   type: Opaque
   stringData:
     # either IBMCLOUD_API_KEY or IBMCLOUD_IAM_PROFILE_ID must be set
     # if you specify both the IBMCLOUD_API_KEY will be used
     # IBMCLOUD_IAM_ENDPOINT is optional
     IBMCLOUD_API_KEY: "$IBMCLOUD_API_KEY"
     IBMCLOUD_IAM_ENDPOINT: "https://iam.cloud.ibm.com/identity/token"
     IBMCLOUD_IAM_PROFILE_ID: "$IBMCLOUD_TRUSTED_PROFILE_ID"
   EOF
   

7. Appliquez le secret au cluster.

   oc apply -f peer-pods-secret.yaml
   

8. Exécutez la commande pour créer le fichier peer-pods-cm.yaml ConfigMap. Supprimez toutes les variables d'environnement facultatives de la section data que vous n'avez pas définies.

   cat > peer-pods-cm.yaml <<EOF
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: peer-pods-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     CLOUD_PROVIDER: "ibmcloud"
     IBMCLOUD_PODVM_IMAGE_ID: "$PODVM_IMAGE_ID"
     IBMCLOUD_PODVM_INSTANCE_PROFILE_LIST: "bx3dc-2x10"
     IBMCLOUD_PODVM_INSTANCE_PROFILE_NAME: "bx3dc-2x10"
     IBMCLOUD_RESOURCE_GROUP_ID: "$(ibmcloud is vpc "$VPC_ID" -json | jq -r .resource_group.id)"
     IBMCLOUD_SSH_KEY_ID: "$SSH_KEY_ID"
     IBMCLOUD_VPC_ID: "$VPC_ID"
     IBMCLOUD_VPC_SG_ID: "$(ibmcloud ks security-group ls --cluster $CLUSTER_NAME -json | jq -r '.[] | select(.type == "cluster") | .id')"
     CLOUD_CONFIG_VERIFY: "false"
     CRI_RUNTIME_ENDPOINT: "/run/cri-runtime/containerd.sock"
     ENABLE_CLOUD_PROVIDER_EXTERNAL_PLUGIN: "false"
     VXLAN_PORT: ""
     TUNNEL_TYPE: ""
     INITDATA: ""
     PEERPODS_LIMIT_PER_NODE: "10"
   EOF
   

   Le paramètre PEERPODS_LIMIT_PER_NODE contrôle le nombre maximum de VSI de pods homologues qui peuvent être planifiés par nœud de travail. La valeur par défaut est 10. Vous pouvez augmenter cette valeur en fonction de la capacité de votre nœud de travailleur, mais notez que vous êtes également contraint par les limites de pods de Kubernetes (110 pods par nœud pour un travailleur 16x64 ) et les ressources CPU disponibles sur le nœud de travailleur. Chaque pod pair consomme environ 250m de CPU et 120Mi de mémoire sur le nœud de travail pour la construction du pod Kubernetes, même si la charge de travail réelle s'exécute dans un VSI séparé. Pour plus d'informations, voir la Foire aux questions.

9. Appliquer le site ConfigMap.

   oc apply -f peer-pods-cm.yaml
   

10. Exécutez la commande pour créer le fichier kata-runtime-settings.yaml KataConfig.

    cat > kata-runtime-settings.yaml <<EOF
    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: kata-runtime-settings
      namespace: openshift-sandboxed-containers-operator
    spec:
      enablePeerPods: true
      logLevel: info
     #checkNodeEligibility: true
     #kataConfigPoolSelector:
     #  matchLabels:
     #    <label_key>: '<label_value>'
    EOF
    

11. Appliquer le site KataConfig.

    oc apply -f kata-runtime-settings.yaml
    

12. Au fur et à mesure de l'installation de Kata et du démarrage des démons, vous pouvez suivre l'évolution de la situation.

    • Vous pouvez consulter le projet OperatorHub openshift-sandboxed-containers-operator pour voir que le site KataConfig est en cours.
    • Vous pouvez exécuter la commande suivante pour voir les étiquettes se mettre à jour avec l'état actuel de l'installation.

        oc get nodes --output yaml|egrep "kata-ds-rpm-install|ibm-cloud.kubernetes.io/worker-id"
        ```
        États possibles :
    
        - `waiting_to_install`: L'installation de Kata est en file d'attente sur le nœud.
        - `installing`: L'installation des Kata est en cours.
        - `installed`: Kata est installé avec succès sur le nœud.
        - `waiting_for_reboot`: Le nœud doit être redémarré pour terminer l'installation ou la désinstallation.
        - `waiting_to_uninstall`: La désinstallation de Kata est en file d'attente sur le nœud.
        - `uninstalling`: La désinstallation de Kata est en cours.
        - `uninstalled`: Kata est désinstallé avec succès du nœud.
    
    

13. Lorsque les étiquettes sont mises à jour et se trouvent à l'état waiting_for_reboot, redémarrez chaque nœud de travail un par un.

Lorsque vous exécutez oc get nodes et que chaque nœud de travail est dans l'état installed, l'installation est terminée.

Étape 7 : Configuration d'une autorité de confiance

L'attestation est un élément essentiel des conteneurs confidentiels. Vous devez valider la sécurité du code de la chaîne d'approvisionnement, c'est-à-dire que le code exécuté dans le conteneur n'a pas été modifié. Vous pouvez utiliser une puce Intel TDX et le protocole key-broker-service. L'image du site podvm contient déjà le code du pilote TDX et un site kbs_client. Vous devez cependant configurer l'INITDATA avec les détails de l'administrateur.

1. Sélectionnez un administrateur. Il existe de nombreuses options pour les conteneurs confidentiels.

   • À des fins de développement, vous pouvez lancer un site VM à l'intention d'un administrateur.

   • Pour un service de production, vous pouvez utiliser Intel Trust Authority.

2. Si vous avez choisi le site VM pour un administrateur à des fins de développement, effectuez les étapes de configuration suivantes.

   a. Insérez l'adresse IP de l'administrateur dans le script suivant et exécutez-le pour définir la variable INITDATA.

   export KBS_SERVICE_ENDPOINT="https://REPLACE_WITH_TRUSTEE_IP:8080"
   export INITDATA=$(cat <<EOF | gzip | base64 -w0
   algorithm = "sha256"
   version = "0.1.0"
   [data]
   "aa.toml" = '''
   [token_configs]
   [token_configs.coco_as]
   url = "$KBS_SERVICE_ENDPOINT"
   [token_configs.kbs]
   url = "$KBS_SERVICE_ENDPOINT"
   '''
   "cdh.toml"  = '''
   socket = 'unix:///run/confidential-containers/cdh.sock'
   credentials = []
   [kbc]
   name = "cc_kbc"
   url = "$KBS_SERVICE_ENDPOINT"
   '''
   EOF
   )
   

   b. Vérifiez la variable d'environnement $INITDATA.

   echo $INITDATA
   

   c. Ajoutez la valeur de la variable à peer-pods-cm.yaml ConfigMap dans l'espace de noms openshift-sandboxed-containers-operator.

   d. Redémarrer le daemonset osc-caa-ds dans l'espace de noms openshift-sandboxed-containers-operator. Ce daemonset Cloud API Adapter est utilisé pour communiquer avec IBM Cloud.

   oc rollout restart daemonset.apps/osc-caa-ds
   

   e. Exécutez la commande suivante pour afficher les pods. Pour chaque pod osc-caa-ds-<id>, regardez l'âge de chaque pod pour vérifier que le pod a été redémarré.

   oc get pods
   

   Si un module n'a pas redémarré, supprimez le module pour le recréer.

   oc delete pod/osc-caa-ds-<id>
   

   Visualisez à nouveau les cosses.

   oc get pods
   

   f. Répétez ces étapes pour chaque entrée de charge de travail de INITDATA.

   . La valeur INITDATA peut être appliquée à un conteneur individuel sous forme d'annotation et le conteneur qui démarre est configuré pour utiliser le mandataire. Cette annotation peut être utile pour tester de nouveaux administrateurs ou pour s'assurer que les modifications apportées à INITDATA ne brisent pas les conteneurs confidentiels.

   Exemple d'annotation :

   apiVersion: v1
   kind: Pod
     metadata:
       name: mypod
       annotations:
         io.katacontainers.config.runtime.cc_init_data: $INITDATA
   spec:
     runtimeClassName: kata-remote
   

Étape 8 : Exécution d'une charge de travail confidentielle dans un conteneur

Une fois que toutes les étiquettes ont été mises à jour vers installed, déployez une charge de travail en utilisant le nom de la classe d'exécution kata-remote dans un fichier pod.yaml. Vous pouvez utiliser l'exemple Hello World comme charge de travail de test dans un conteneur confidentiel.

1. Créez un fichier pod.yaml.

   oc apply -f - <<EOF
   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       app: helloworld
       version: v1
     name: helloworld
   spec:
     containers:
     - name: helloworld
       image: docker.io/istio/examples-helloworld-v1:1.0
       ports:
       - containerPort: 5000
     runtimeClassName: kata-remote
   EOF
   

2. Suivez le déploiement dans la liste Virtual Servers. Lorsque la VSI est créée, elle affiche l'état " Running" (en cours d'exécution). Si l'ISBC semble bloqué à l'état de démarrage, vérifiez les journaux pour voir s'il y a des problèmes.

   a. Obtenez les noms des pods.

   oc get pods
   

   b. Consultez les journaux de l'un des pods de l'adaptateur API Cloud et recherchez les erreurs.

   oc logs osc-caa-ds-<id>
   

3. Vérifiez le pod en exécutant la commande suivante.

   oc describe pod/helloworld
   

4. Pour vérifier l'attestation, entrez dans le conteneur en exécutant la commande suivante.

   oc exec -it helloworld -- bash
   

   Ensuite, exécutez la commande suivante curl pour obtenir des informations de l'administrateur.

   curl http://127.0.0.1:8006/cdh/resource/default/kbsres1/key1
   

   Lorsque vous avez terminé, vous pouvez quitter le conteneur.

   exit
   

5. En cas de problème, consultez les journaux dans l'espace de noms openshift-sandboxed-containers-operator.

   • Journaux des pods gérés par le contrôleur :

       oc logs pod/controller-manager-<UNIQUE_ID>
       ```
   - Journaux des pods de l'adaptateur API Cloud :
   
   ```sh {: pre}
       oc logs pod/osc-caa-ds-<UNIQUE_ID>
       ```
   - Journaux d'application : Dépend de l'emplacement spécifié.
   
   

L'installation de vos conteneurs confidentiels est maintenant terminée! Vous avez encore besoin d'aide ? Vérifier le dépannage.

Suppression des charges de travail et des outils

Si vous suivez ces étapes dans le mauvais ordre, vous risquez de laisser derrière vous des ressources qui vous seront facturées, telles qu'un ISV.