Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Kubernetes Service (AKS) clusters utilisent des certificats pour l’authentification entre différents composants, y compris les composants du plan de contrôle managé AKS et les composants du plan de données. Cet article fournit une vue d’ensemble de la gestion et de la rotation des certificats dans AKS.
Important
À compter du 1er avril 2027, Azure Kubernetes Service (AKS) ne prend plus en charge la aks-disable-kubelet-serving-certificate-rotation=true balise de pool de nœuds pour désactiver la rotation des certificats de service Kubelet (KSCR). Vous pouvez créer des pools de nœuds à l’aide de cette balise, mais AKS ne le respecte pas. Ce comportement signifie que les pools de nœuds seront créés avec KSCR activé. Pour les pools de nœuds existants, KSCR sera automatiquement activé lors de leur prochaine opération de réimage. Avant cette date, vous pouvez mettre à jour vos pools de nœuds à l’aide de la az aks nodepool update commande avec la aks-disable-kubelet-serving-certificate-rotation=true balise. Afin de vous préparer à la suppression, il est recommandé de mettre à jour vos charges de travail avec le chemin d’accès correct au certificat. Pour plus d’informations, consultez le problème GitHub de mise hors service. Pour rester informé des annonces et des mises à jour, suivez les notes de publication d’AKS.
Remarque
L’autorotation de certificat pour le client de nœud et les certificats de service est activée par défaut pour les clusters qui activent RBAC Kubernetes.
- Les clusters AKS créés avant mai 2019 ont des certificats d’autorité de certification de cluster qui expirent après deux ans.
- Les clusters AKS créés après mai 2019 ont des certificats d’autorité de certification de cluster qui expirent après 30 ans.
Qu’est-ce que la rotation des certificats ?
La rotation des certificats est le processus de remplacement des certificats numériques par de nouveaux certificats pour maintenir la sécurité et empêcher les interruptions. Il s’agit d’une pratique de sécurité cruciale effectuée pour remplacer les certificats expirés, atténuer les risques liés aux clés compromises et répondre aux nouvelles exigences de sécurité. Ce processus peut impliquer le renouvellement automatique des certificats ou leur remplacement manuel. Souvent, une fenêtre de maintenance planifiée est nécessaire lors de remplacements complexes, en particulier lorsqu’un certificat racine entre en jeu.
Certificats, autorités de certification et jetons de compte de service dans AKS
AKS génère et utilise les certificats, les autorités de certification (CA) et les jetons de comptes de service (SA) suivants :
| Certificate | Description | Méthode de rotation |
|---|---|---|
| Autorité de certification de cluster | Créé par AKS en votre nom et est unique à votre cluster. Ce certificat d’autorité de certification est utilisé pour émettre à la fois des certificats client et serveur pour les kubelets s’exécutant dans votre plan de données, ainsi que le certificat utilisé par le serveur d’API. | Manual |
| Jeton de compte de service | Jetons web JSON (JWT) signés par le certificat d’autorité de certification du cluster. Les kubelets s’exécutant sur vos nœuds d’agent demandent et renouvellent automatiquement ces jetons. Pour plus d’informations, consultez Lancer un pod à l’aide de la projection du jeton de compte de service. | Mis à jour automatiquement dans le cadre de la rotation manuelle de l’autorité de certification du cluster |
| Certificat de serveur d’API | Signé et émis par le certificat de l’autorité de certification du cluster. Ce certificat est utilisé chaque fois que vous établissez des connexions TLS avec le serveur d’API, par exemple avec kubectl. |
Mis à jour automatiquement dans le cadre de la rotation manuelle de l’autorité de certification du cluster |
| certificat serveur du Kubelet | Dans les clusters qui activent la rotation du certificat de service kubelet, le certificat de l’autorité de certification du cluster délivre et signe ce certificat. Sinon, le nœud de l’agent génère et signe automatiquement ce certificat. Ce certificat établit des connexions basées sur TLS avec les composants qui doivent se connecter à l’un des points de terminaison de service du kubelet, tels que metrics-server. | Automatique pour les clusters sur lesquels la rotation des certificats de service du kubelet est activée |
| Certificat client du kubelet | Signé et émis par le certificat de l’autorité de certification du cluster. Ce certificat utilise un protocole de démarrage TLS spécifique à AKS qui fournit kubelet son certificat client et kubeconfig correspondant avant le démarrage de kubelet. Le protocole TLS AKS est activé uniquement sur les clusters Kubernetes version 1.32 ou ultérieure. | Automatiquement renouvelé par défaut via l’initialisation TLS standard et dans le cadre de la rotation manuelle de l’autorité de certification du cluster |
kubectl certificat client |
Utilisé pour l’authentification basée sur des certificats avec le serveur d’API. | Rotation manuelle après la rotation manuelle de l’autorité de certification du cluster |
Remarque
AKS ne gère aucun certificat créé ou spécifique à la charge de travail d’un client.
Rotation automatique des certificats sur AKS
AKS fait pivoter automatiquement les certificats suivants :
- Les clusters créés après mars 2022 avec Kubernetes RBAC activé activent l’autorotation du certificat client kubelet par défaut.
Remarque
Vous devrez peut-être faire pivoter ces certificats manuellement pour des raisons de sécurité ou de stratégie. Par exemple, vous pouvez avoir une stratégie pour renouveler tous vos certificats tous les 90 jours. Par défaut, l’autorotation du certificat client kubelet se produit manuellement.
Limites de la rotation automatique des certificats
Les limitations suivantes s’appliquent à la rotation automatique du certificat :
- Le cluster doit utiliser le démarrage TLS vanille ou le démarrage TLS sécurisé AKS, qui est déployé par défaut pour toutes les régions Azure.
- Pour les clusters existants, vous devez mettre à niveau le cluster pour activer l’autorotation de certificat.
Rotation manuelle des certificats dans AKS
Vous devez faire pivoter manuellement les certificats suivants :
- Certificats CA du cluster avec le
az aks rotate-certs. -
kubectlcertificats clients à l’aide de la commandeaz aks get-credentials(après rotation manuelle du certificat de l’autorité de certification du cluster).
Lorsque vous faites pivoter le certificat d’autorité de certification du cluster, les certificats enfants suivants sont également actualisés :
- Jetons de compte de service (SA)
- Certificats de serveur d’API
- Certificats client de Kubelet
- Certificats de serveur Kubelet (si kubelet servant la rotation des certificats est activé sur le cluster)
Après avoir fait pivoter le certificat d’autorité de certification du cluster, vous devez également faire pivoter manuellement les kubectl certificats clients pour garantir un accès continu au serveur d’API.
Démarrage TLS pour le certificat client kubelet
Kubelet utilise un protocole de démarrage TLS spécifique à AKS et s'appuie sur l'identité du nœud dans Entra ID. Cette identité fournit à kubelet son certificat client et le kubeconfig correspondant avant son démarrage. Cette modification vise à renforcer la posture de sécurité des nœuds AKS en éliminant la dépendance de kubelet sur un secret de jeton d’amorçage statique pour s’inscrire auprès du serveur d’API. Si le protocole de démarrage TLS sécurisé échoue pour une raison quelconque, kubelet peut toujours s’inscrire auprès du serveur d’API à l’aide d’un jeton de démarrage, et le nœud est finalement prêt. Vous voyez aksService (au lieu de system:bootstrap:<>) comme champ demandeur sur les objets de demande de signature de certificat (CSR) créés par le protocole.
Le certificat client kubelet se trouve toujours dans /var/lib/kubelet/pki/kubelet-client-current.pem sur les nœuds Linux et C :\k\pki\kubelet-client-current.pem sur les nœuds Windows. Le bootstrap-kubeconfig se trouve toujours au même endroit. AKS continue de faire pivoter automatiquement ce certificat dans le cadre de son processus de rotation de certificat.
Kubelet servant la rotation des certificats
La rotation des certificats de service Kubelet permet à AKS d’utiliser le démarrage TLS du serveur kubelet à la fois pour le démarrage et la rotation des certificats de service que l’autorité de certification du cluster signe.
Pour plus d’informations, consultez Gérer et faire pivoter des certificats dans Azure Kubernetes Service (AKS).
Limitations de la rotation des certificats de serveur du kubelet
- Pris en charge sur Kubernetes version 1.27 et ultérieures.
- Il n’est pas pris en charge lorsque le pool de nœuds utilise un instantané de pool de nœuds basé sur une image de nœud antérieure à
202501.12.0. - Vous ne pouvez pas activer cette fonctionnalité manuellement. Les pools de nœuds existants bénéficient de la rotation des certificats de service du kubelet activée par défaut après leur première mise à niveau vers une version 1.27 ou ultérieure de Kubernetes. Les nouveaux pools de nœuds sur Kubernetes version 1.27 ou ultérieure ont kubelet servant la rotation des certificats activée par défaut. Pour voir si la rotation des certificats de service kubelet est activée dans votre région, consultez les versions AKS.
- Le RBAC de Kubernetes doit être activé sur le cluster pour pouvoir activer la rotation des certificats de service du kubelet. Si vous disposez d’un cluster existant, vous devez mettre à niveau ce cluster pour activer RBAC Kubernetes.