Rotation des informations d'identification de cluster

Découvrez comment faire pivoter les informations d'identification des clusters créés à l'aide de Kubernetes Engine (OKE).

Pour activer la communication sécurisée TLS (anciennement SSL) vers, depuis et au sein des clusters, Kubernetes utilise des certificats PKI (Public Key Infrastructure) pour l'authentification. Pour plus d'informations sur les certificats PKI et les clusters Kubernetes, reportez-vous à Certificats et exigences PKI dans la documentation Kubernetes.

Les clusters que vous créez avec Kubernetes Engine ont des autorités de certification racine PKI (autorités de certification) et des clés privées pour le cluster, le composant etcd et le composant de proxy avant. Ces autorités de certification racine sont utilisées pour signer les certificats et les clés privées utilisés dans le cluster. Les autorités de certification racine, les certificats signés et les clés privées utilisés dans le cluster sont collectivement appelés informations d'identification de cluster.

Dans les clusters que vous créez avec Kubernetes Engine, les autorités de certification racine expirent au bout de cinq ans. Pour continuer à utiliser un cluster, vous devez modifier (ou "faire pivoter") les informations d'identification du cluster avant la fin de la période de cinq ans. En outre, votre organisation peut avoir mis en place des directives et des stratégies de sécurité qui nécessitent une rotation plus fréquente des informations d'identification de cluster (dans certains cas, beaucoup plus fréquente). Des messages vous informant de l'expiration prochaine des informations d'identification de cluster sont affichés dans la console. Vous pouvez également utiliser la console, l'interface de ligne de commande et l'API pour savoir quand les informations d'identification de cluster doivent expirer.

Lorsque vous effectuez la rotation des informations d'identification de cluster, vous devez mettre à jour les clients d'API Kubernetes qui utilisaient les informations d'identification précédentes pour communiquer avec l'API Kubernetes. Ces clients d'API Kubernetes incluent des fichiers kubeconfig et des pods qui communiquent directement avec l'API Kubernetes.

La rotation des informations d'identification du cluster s'effectue en trois étapes :

• Etape 1, lancement de la phase de démarrage de la rotation des informations d'identification : pendant la phase de démarrage de la rotation des informations d'identification, de nouvelles autorités de certification racine, de nouvelles clés privées et de nouveaux certificats sont créés. Vous pouvez lancer la phase Démarrer la rotation des informations d'identification à tout moment, mais vous devez démarrer la rotation des informations d'identification avant l'expiration des informations d'identification. Le démarrage de la rotation des informations d'identification avant l'expiration des informations d'identification permet également d'éviter toute interruption de service.

  Lorsque vous lancez la phase Démarrer la rotation des informations d'identification, vous indiquez explicitement la durée d'une "période de retard" avant que la phase Terminer la rotation des informations d'identification soit lancée automatiquement. La période de retard vous permet de mettre à jour les clients d'API Kubernetes (étape 2). Pendant la période de retard, les informations d'identification héritées et les nouvelles informations d'identification fournissent une communication sécurisée vers, depuis et au sein du cluster. Le délai que vous spécifiez doit être d'au moins 1 jour et d'au plus 90 jours. Vous pouvez lancer manuellement la phase de rotation complète des informations d'identification avant la fin de la période de retard, à condition que les nouvelles informations d'identification datent d'au moins 24 heures et que vous ayez terminé avec succès l'étape 2.

  Ne démarrez pas l'étape 2 tant que les nouvelles autorités de certification racine, clés privées et certificats n'ont pas été créés.

  Remarque
  
  Lorsque vous utilisez l'interface de ligne de commande ou l'API pour lancer la phase de démarrage de la rotation des informations d'identification, indiquez la durée de la période de délai au format de durée ISO 8601. Par exemple :

  • utilisez P5D pour indiquer cinq jours
  • utilisez P5DT5H pour indiquer cinq jours et cinq heures
  • utilisez P5DT5H5M pour indiquer cinq jours, cinq heures et cinq minutes

  Pour plus d'informations sur le format de durée ISO 8601, effectuez une recherche en ligne.

• Etape 2, mise à jour des clients d'API Kubernetes : lorsque les nouvelles autorités de certification racine, clés privées et certificats ont été créées, et dans le délai que vous avez indiqué (pas moins de 1 jour et pas plus de 90 jours) :
  • Configurez de nouveaux fichiers kubeconfig pour permettre l'accès au cluster à l'aide des nouvelles informations d'identification et des anciennes.
  • Recréez ou redémarrez les noeuds de processus actif hébergeant des pods qui communiquent directement avec le serveur d'API Kubernetes (ou pour éviter toute interruption des noeuds de processus actif, redémarrez simplement les pods eux-mêmes). Si le cluster contient des noeuds virtuels, redémarrez tous les pods exécutés sur les noeuds virtuels.

  Ne démarrez pas l'étape 3 tant que vous n'avez pas configuré de nouveaux fichiers kubeconfig et que vous n'avez pas recréé ou redémarré les noeuds de processus actif (ou simplement redémarré les pods).

• Etape 3, Lancer la phase Terminer la rotation des informations d'identification : lorsque vous avez terminé l'étape 2, et dans le délai que vous avez indiqué (pas moins de 1 jour et pas plus de 90 jours), vous pouvez lancer manuellement la phase Terminer la rotation des informations d'identification. Au cours de la phase de rotation complète des informations d'identification, les autorités de certification root héritées, les clés privées et les certificats sont retirés et supprimés. Lancez la phase Terminer la rotation des informations d'identification au plus tôt 24 heures après avoir lancé la phase Démarrer la rotation des informations d'identification et seulement après avoir terminé l'étape 2. Si les nouvelles informations d'identification datent d'au moins 24 heures, vous pouvez lancer la phase de rotation complète des informations d'identification dès que vous êtes prêt.

  Si vous ne lancez pas manuellement la phase de rotation complète des informations d'identification pendant la période de retard que vous avez spécifiée (pas moins de 1 jour et pas plus de 90 jours), la phase de rotation complète des informations d'identification est automatiquement lancée à la fin de la période de retard.

  Une fois la phase de rotation complète des informations d'identification terminée, nous vous recommandons de remplacer tout fichier kubeconfig créé au cours de l'étape 2 (qui contiendra à la fois les informations d'identification héritées et les nouvelles informations d'identification) par un nouveau fichier kubeconfig contenant uniquement les nouvelles informations d'identification. Si le cluster contient des noeuds virtuels, nous vous recommandons également de redémarrer tous les pods exécutés sur les noeuds virtuels.

Les phases Démarrer la rotation des informations d'identification et Terminer la rotation des informations d'identification sont générées dynamiquement en tant que demandes de travail distinctes. Pour suivre la progression des phases Démarrer la rotation des informations d'identification et Terminer la rotation des informations d'identification, affichez le statut de la demande de travail correspondante. Reportez-vous à Affichage des demandes de travail.

Vous pouvez effectuer la rotation des informations d'identification de cluster à l'aide de la console, de l'interface de ligne de commande et de l'API.

Tenez compte des points suivants lors de la rotation des informations d'identification de cluster :

• La rotation des informations d'identification est prise en charge pour les clusters exécutant Kubernetes version 1.20 ou ultérieure.
• La simple mise à niveau de la version de Kubernetes sur le plan de contrôle du cluster n'entraîne pas la rotation des informations d'identification. Vous devez effectuer toutes les étapes du processus de rotation des informations d'identification.
• La phase Démarrer la rotation des informations d'identification et la phase Terminer la rotation des informations d'identification ne peuvent commencer que lorsque tous les noeuds de processus actif du cluster (noeuds gérés, noeuds virtuels, noeuds autogérés) ont le statut READY. Si le statut d'un ou de plusieurs noeuds de processus actif passe à NOT READY pendant la rotation des informations d'identification, les opérations de rotation des informations d'identification s'interrompent jusqu'à 24 heures, en attendant que tous les noeuds aient à nouveau le statut READY avant la reprise. Si un ou plusieurs noeuds de processus actif ont toujours le statut NOT READY après 24 heures, les opérations de rotation des informations d'identification expirent.
• Si la phase Démarrer la rotation des informations d'identification ou la phase Terminer la rotation des informations d'identification échoue pour une raison quelconque, les informations d'identification héritées continuent de fonctionner et ne sont pas mises hors service tant qu'elles n'expirent pas.
• Si vous ne lancez pas manuellement la phase de rotation complète des informations d'identification dans le délai que vous avez indiqué (pas moins de 1 jour et pas plus de 90 jours), la phase de rotation complète des informations d'identification est lancée automatiquement. Si vous n'avez pas mis à jour les clients d'API Kubernetes avant la fin de la période de retard, le cluster subira une interruption de service.