Rotation des certificats Red Hat OpenShift

Red Hat OpenShift for VMware utilise des certificats client kubelet qui doivent faire l'objet d'une rotation périodique à des fins de sécurité. Red Hat OpenShift automatise principalement le processus de rotation, mais nécessite l'approbation manuelle des demandes de signature de certificat (RSC).Par conséquent, il est important que vous compreniez le planning de rotation des certificats Red Hat OpenShift afin d'éviter les certificats arrivés à expiration.

Les certificats initiaux créés lors de l'installation expirent 24 heures après leur création.Le processus d'automatisation d'IBM, qui installe Red Hat OpenShift, gère l'approbation des demandes de signature de certificat pour cette rotation initiale en exécutant un script sur le bastion pendant les 30 premières heures.Le script se nomme /root/approve-csr.sh et son fichier journal se nomme /root/approve-csr.log.

Pour que le script s'exécute correctement, les données d'identification kubeadmin initiales doivent être identiques jusqu'à ce que la rotation initiale du certificat soit terminée. Ne modifiez pas les données d'identification kubeadmin pendant les premières 24 heures.Si vous modifiez les données d'identification, vous devez surveiller et approuver les demandes de signature de certificat pour la rotation initiale du certificat.Pour plus d'informations, voir Approbation des CSR pour vos machines.

Ne redémarrez pas les machines virtuelles de cluster Red Hat OpenShift (VM) ou la machine virtuelle du bastion jusqu'à ce que la première rotation des certificats soit effectuée.

Après la rotation initiale du certificat, les certificats sont renouvelés tous les 30 jours.Vous devez définir un processus d'approbation des demandes de signature de certificat pour chaque rotation de certificat.Selon Red Hat®, vous pouvez approuver les demandes de signature de certificat lorsqu'elles atteignent 80 % de leur période de validité, ce qui correspond à environ 25 jours de leur cycle de vie.

Si vous n'approuvez pas les demandes de signature de certificat à temps et que les certificats expirent, vous pouvez effectuer une reprise à partir des certificats de plan de contrôle arrivés à expiration et rétablir le fonctionnement du cluster Red Hat OpenShift. Pour plus d'informations, voir Récupération des certificats de plan de contrôle expirés.

Redimensionnement de vos VM Red Hat OpenShift

1. Connectez-vous à la machine virtuelle via SSH.
2. Utilisez le nom d'utilisateur root : sudo -i
3. Arrêtez la machine virtuelle cible : ssh core@<vm-ip> sudo shutdown -h 0
4. Après avoir mis la machine virtuelle hors tension, redimensionnez-la dans vCenter Server.
5. Mettez la machine virtuelle sous tension.
6. Dans la console Red Hat OpenShift, accédez à Calculer > Noeuds et attendez que la machine virtuelle qui a été redémarrée soit de retour dans un état Prêt.
7. Suivez les étapes précédentes pour toutes les machines virtuelles.

Changer la clé SSH sur le bastion Red Hat OpenShift VM

La paire de clés SSH générée lors de l'installation se trouve sur la machine virtuelle du bastion Red Hat OpenShift.L'emplacement de la paire de clés SSH s'affiche dans la page des détails du service Red Hat OpenShift. Cette clé SSH a été installée sur toutes les machines virtuelles du cluster pour autoriser l'établissement de connexions SSH à partir du bastion sans mot de passe.

Il est recommandé qu'une nouvelle paire de clés SSH soit générée et utilisée pour remplacer la clé existante.Pour plus d'informations sur la manière de générer une nouvelle paire de clés Pour plus d'informations sur la génération d'une nouvelle paire de clés SSH, voir Comment mettre à jour les clés SSH après l'installation sur Red Hat OpenShift. Vous devez exécuter les commandes à partir de la machine virtuelle du bastion. Pour plus d'informations sur la connexion au bastion, voir Détails relatifs au bastion.

Extension du cluster Red Hat OpenShift avec plus de travailleurs

Pour développer votre cluster Red Hat OpenShift en ajoutant d'autres machines virtuelles worker, procédez comme suit :

1. Créez un travailleur VM à partir du modèle RHCOREOS :

   1. Vérifiez que la machine virtuelle est connectée au même réseau que les autres machines virtuelles de travail Red Hat OpenShift.
   2. Ne mettez pas encore ce site VM sous tension car d'autres étapes de configuration sont nécessaires.

2. Préparer un dossier d'allumage du travailleur sur le bastion :

   1. Pour plus d'informations sur la connexion au bastion, voir Détails relatifs au bastion.
   2. Dans le répertoire d'installation sur le bastion, recherchez le fichier ignition worker nommé worker.ign. Créez une version en Base64 de ce fichier à l'aide de la commande base64 -w0 worker.ign > worker.ign.b64. Vous utiliserez le contenu du fichier worker.ign.b64 nouvellement créé dans l'étape suivante.

3. Définir les attributs de VM:

   1. Avant de commencer, éteignez l'ordinateur VM. Ensuite, allez dans la fenêtre Paramètres de configuration, sélectionnez le nouveau travailleur VM, et cliquez sur Actions > Modifier les paramètres.
   2. Dans la fenêtre d'édition des paramètres, cliquez sur l'onglet VM Options. A gauche, cliquez sur Avancé pour développer la section Avancé dans la fenêtre. Faites ensuite défiler vers le bas jusqu'aux paramètres de configuration sur la gauche.  Cliquez sur Editer la configuration.
   3. La fenêtre des paramètres de configuration peut comporter une longue liste de paramètres existants pour la machine virtuelle. Pour ajouter une valeur, cliquez sur Add Configuration Params. Deux zones vides libellées Name et Value s'affichent pour être renseignées. Utilisez ce processus pour les trois étapes suivantes.
   4. Créez une valeur nommée guestinfo.ignition.config.data et définissez-la en fonction du contenu du fichier de configuration d'allumage base64-encoded worker.ign.b64 qui a été créé précédemment.
   5. Créez une valeur nommée guestinfo.ignition.config.data.encoding et attribuez-lui la valeur de la chaîne base64.
   6. Créez une valeur nommée disk.EnableUUID et attribuez-lui la valeur de la chaîne TRUE.
   7. Après avoir créé les nouveaux paramètres, cliquez deux fois sur OK pour fermer les fenêtres ouvertes.

4. Créez une liaison DHCP pour la machine virtuelle worker :

   1. Connectez-vous à NSX-T™.
   2. Accédez à Networking > Segments.
   3. Editez le segment ocp-internal.
   4. Développez DHCP Static Bindings et cliquez sur Set pour ouvrir la fenêtre de définition des liaisons statiques.
   5. Consultez la liste des liaisons existantes et notez la prochaine adresse IP disponible.
   6. Examinez l'une des liaisons worker existantes pour consulter les informations dont vous aurez besoin par la suite. Notez l'adresse de la passerelle et les options DHCP. Pour afficher les options DHCP, cliquez sur Set en regard de DHCP Options. Dans la fenêtre Options, sélectionnez Generic Options dans la liste Select DHCP Option. Notez les options définies.
   7. Fermez la liaison existante que vous avez examinée pour revenir à la fenêtre de définition des liaisons statiques.
   8. Cliquez sur Add IPV4 Static Binding. Complétez les détails de la nouvelle liaison worker, y compris les options DHCP que vous aviez notées précédemment.
   9. Lorsque vous avez terminé, cliquez sur Save pour valider les modifications.

5. Ajoutez une machine virtuelle worker aux pools d'équilibreurs de charge :

   1. Accédez à Networking > Load Balancer > Server Pools.
   2. Modifier le pool de serveurs ocp-apps.
   3. Dans la fenêtre d'édition, sous Members/Group, cliquez sur le lien numérique bleu. La valeur par défaut est 3.
   4. Lorsque la fenêtre Configure Server Pool Members s'ouvre, cliquez sur Add Member.
   5. Entrez le nom et l'adresse IP du nouveau noeud worker. Laissez la zone de numéro de port vide.
   6. Cliquez sur Sauvegarder puis cliquez sur Appliquer.

6. Créez des enregistrements DNS pour le nouveau travailleur :

   1. Connectez-vous au serveur AD NS de votre instance VCF for Classic - Automated.
   2. A l'aide du gestionnaire DNS, ajoutez un nouvel enregistrement A à la zone ocp correspondante. Lorsque vous créez l'enregistrement A, assurez-vous que l'option de création d'un enregistrement PTR associé est sélectionnée.

7. Validez toutes les demandes de signature de certificat du bastion. Pendant le provisionnement du nouveau travailleur, il se peut que vous deviez approuver des CSR à partir du bastion :

   1. Connectez-vous à bastion en tant qu'utilisateur root et allez dans le répertoire d'installation de bastion. Pour plus d'informations, voir Détails de la base.

   2. Avant de pouvoir exécuter des commandes, vous devez vous authentifier auprès de Red Hat OpenShift:

      • Si l'authentification n'est pas configurée et que vous utilisez le compte et le mot de passe kubeadmin par défaut, exécutez la commande export KUBECONFIG=auth/kubeconfig et vérifiez que vous êtes authentifié en exécutant la commande ./oc whoami.
      • Si d'autres back-end ou utilisateurs sont authentifiés, connectez-vous à l'aide de l'un de ces comptes, comme expliqué dans la documentation Red Hat OpenShift, par exemple, en exécutant la commande ./oc login.

   3. Exécutez ./oc get nodes pour voir la nouvelle machine virtuelle worker.S'il n'est pas dans l'état Prêt, vérifiez à plusieurs reprises les CSR en attente à l'aide de la commande ./oc get csr, puis approuvez les CSR à l'aide de la commande ./oc adm certificate approve <csr_name>.Continuez à vérifier jusqu'à ce que la configuration soit terminée et que le nouveau travailleur soit dans l'état Prêt.

      Une fois que la nouvelle machine virtruelle worker est à l'état Prêt, elle peut être utilisée par Red Hat OpenShift.

8. Mettez le VM sous tension :

   • Une fois la machine virtuelle sous tension, vous pouvez la surveiller afin de détecter un éventuel problème.La machine virtuelle obtient une adresse IP, traite le fichier ignition, puis ouvre une invite de connexion.

   • Une fois l'invite de connexion affichée, elle peut être couverte par des messages de journal de la console.Si nécessaire, appuyez plusieurs fois sur la touche Entrée de la console. Si l'invite de connexion est présente mais couverte par des messages de la console, appuyez sur Entrée pour afficher à nouveau l'invite de connexion.

   • Si l'invite de connexion ne s'affiche pas, il est possible que.. :

     • Que la machine virtuelle ne parvient pas à obtenir d'adresse IP. Vérifiez le réseau auquel elle est connectée. Vérifiez également les paramètres de liaison DHCP.
     • La valeur base64 de worker.ign.64 n'est pas correcte. Des caractères peuvent manquer ou être superflus. Vérifiez la valeur.

     Si vous devez modifier des paramètres parce que la machine virtuelle n'affiche pas d'invite de connexion, mettez la machine virtuelle hors tension, modifiez les paramètres requis, puis remettez la machine virtuelle sous tension.

Considérations à prendre en compte lors de la suppression de Red Hat OpenShift pour VMware

• Avant de supprimer Red Hat OpenShift for VMware, vous devez supprimer toutes les machines virtuelles supplémentaires que vous avez créées dans le répertoire ocp sur VMware. L'automatisation de VMware Solutions supprime uniquement les éléments qui ont été déployés lors de l'installation initiale de Red Hat OpenShift (machines virtuelles, stockage et NSX). Tout nœud déployé après l'installation n'est pas supprimé.
• Le VXLAN, le DLR et la passerelle Edge créés lors du déploiement initial de Red Hat OpenShift pour VMware sont supprimés. Les machines virtuelles que vous avez déployées sur VXLAN perdront leur connectivité après la suppression de Red Hat OpenShift pour VMware.
• Si votre cluster utilise le stockage NFS, la suppression de Red Hat OpenShift supprime le magasin de données NFS qui a été ajouté lors de l'installation.
• Si vous utilisez un magasin de données vSAN, supprimez tous les volumes persistants dont vous n'avez plus besoin avant de désinstaller Red Hat OpenShift.Les volumes qui ne sont pas supprimés resteront dans la mémoire vSAN après la désinstallation de Red Hat OpenShift.
• Avant de supprimer le service, vous devez supprimer du stockage toutes les VM personnelles qui ont été déployées avec ce service. Red Hat OpenShift commande uniquement des VM personnelles qui ne sont pas vSAN-based.