Rotation des certificats dans Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) utilise des certificats pour l’authentification avec un grand nombre de ses composants. Vous devez faire pivoter régulièrement ces certificats pour des raisons de sécurité ou de stratégie. Cet article vous montre comment fonctionne la rotation des certificats dans votre cluster AKS.

Prerequisites

• Cet article nécessite la version 2.0.77 ou ultérieure d’Azure CLI. Vérifiez votre version en utilisant la commande az --version. Si vous devez installer ou mettre à niveau, consultez Installer Azure CLI.

• Configurez kubectl pour vous connecter à votre cluster AKS à l’aide de la az aks get-credentials commande :

  az aks get-credentials --resource-group <resource-group> --name <cluster-name>
  

Certificats AKS, autorités de certification et comptes de service

AKS génère et utilise les certificats, autorités de certification et comptes de service suivants :

• Le serveur d’API AKS crée une autorité de certification appelée autorité de certification de cluster, qui signe des certificats pour la communication unidirectionnelle du serveur d’API vers kubelet.
• Chaque kubelet crée une demande de signature de certificat (CSR), que l’autorité de certification de cluster signe, pour la communication du kubelet vers le serveur d’API.
• L’agrégation d’API utilise l’autorité de certification de cluster pour émettre des certificats destinés à la communication avec d’autres API. L’agrégation d’API peut également disposer de sa propre autorité de certification pour émettre ces certificats, mais elle utilise actuellement l’autorité de certification de cluster.
• Chaque nœud d’agent utilise un jeton SA, que l’autorité de certification du cluster signe.
• Le client kubectl dispose d’un certificat pour communiquer avec le cluster AKS.

Microsoft gère tous les certificats mentionnés dans cette section, à l’exception du certificat de cluster.

Dates d’expiration du certificat

Vérifier la date d’expiration du certificat du cluster

• Vérifiez la date d’expiration du certificat de cluster à l’aide de la commande kubectl config view.

  kubectl config view --raw -o jsonpath="{.clusters[?(@.name == '')].cluster.certificate-authority-data}" | base64 -d | openssl x509 -text | grep -A2 Validity
  

Vérifier la date d’expiration du certificat du serveur d’API

• Vérifiez la date d’expiration du certificat de serveur d’API à l’aide de la commande suivante curl :

  curl https://{apiserver-fqdn} -k -v 2>&1 | grep expire
  

Vérifier la date d’expiration du certificat de nœud de l’agent de machine virtuelle

• Vérifiez la date d’expiration du certificat de nœud de l’agent de machine virtuelle à l’aide de la az vm run-command invoke commande.

  Paramètres clés dans cette commande : --resource-group <node-resource-group>- Groupe de ressources qui contient le nœud de l’agent de machine virtuelle. - --name <vm-name>: nom du nœud de l’agent de machine virtuelle. - --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate": script qui récupère la date d’expiration du certificat de serveur d’API situé à /etc/kubernetes/certs/apiserver.crt.

  az vm run-command invoke --resource-group <node-resource-group> --name <vm-name> --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"
  

Vérifier l’expiration du certificat pour le nœud de l’agent Azure Virtual Machine Scale Set

• Vérifiez la date d’expiration du certificat de nœud de l’agent Azure Virtual Machine Scale Set à l’aide de la az vmss run-command invoke commande.

  Paramètres clés dans cette commande : --resource-group <node-resource-group>- Groupe de ressources qui contient le nœud de l’agent Azure Virtual Machine Scale Set. - --name <vmss-name>: Nom du groupe de machines virtuelles identiques Azure. - --instance-id 1: ID d’instance du nœud agent de l'ensemble de machines virtuelles Azure. - --scripts "openssl x509 -in  /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate": script qui récupère la date d’expiration du certificat client kubelet situé à /var/lib/kubelet/pki/kubelet-client-current.pem.

  az vmss run-command invoke --resource-group <node-resource-group> --name <vmss-name> --command-id RunShellScript --instance-id 1 --scripts "openssl x509 -in  /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate" --query "value[0].message"
  

Procéder à la rotation manuelle de vos certificats de cluster

1. Effectuez une rotation de tous les certificats, autorités de certification et comptes de service sur votre cluster à l’aide de la commande az aks rotate-certs.

   az aks rotate-certs --resource-group <resource-group> --name <cluster-name>
   

   Important

   La commande az aks rotate-certs recrée tous vos nœuds d’agent, vos Virtual Machine Scale Sets Azure et vos disques. Cette commande peut également entraîner jusqu’à 30 minutes de temps d’arrêt pour votre cluster AKS. Si la commande échoue avant la fin, utilisez la commande [az aks show][az-aks-show] pour vérifier que l’état du cluster est Certificate Rotating. Si le cluster est dans un état d’échec, réexécutez la az aks rotate-certs commande pour faire pivoter à nouveau vos certificats.

2. Vérifiez que les anciens certificats ne sont plus valides à l’aide d’une kubectl commande. L’exemple suivant utilise la kubectl get nodes commande :

   kubectl get nodes
   

   Si vous n’avez pas mis à jour les certificats utilisés par kubectl, vous voyez une erreur similaire à l’exemple de sortie suivant :

   Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "ca")
   

3. Mettez à jour le certificat utilisé kubectl à l’aide de la commande az aks get-credentials avec l’indicateur --overwrite-existing.

   az aks get-credentials --resource-group <resource-group> --name <cluster-name> --overwrite-existing
   

4. Vérifiez que les certificats sont mis à jour à l’aide de la kubectl get commande.

   kubectl get nodes
   

Si vous avez des services qui s’exécutent sur AKS, vous devrez peut-être également mettre à jour leurs certificats.

Renouveler le certificat de serveur kubelet

Lorsque vous faites pivoter le certificat de service kubelet, AKS autorise le démarrage TLS (Transport Layer Security) du serveur kubelet, à la fois pour le démarrage et la rotation des certificats de service signés par l'autorité de certification (CA) du cluster.

Limitations pour la rotation des certificats de serveur 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. Kubelet servant la rotation des certificats est activé par défaut sur les pools de nœuds existants lorsqu’ils effectuent leur première mise à niveau vers une version Kubernetes 1.27 ou ultérieure. La rotation des certificats Kubelet est activée par défaut sur les nouveaux pools de nœuds avec Kubernetes version 1.27 ou plus. Pour voir si la rotation des certificats de service kubelet est activée dans votre région, vérifiez les versions AKS.

Vérifier que la rotation des certificats de service kubelet est activée

Chaque nœud avec la fonctionnalité activée est automatiquement attribué à l’étiquette kubernetes.azure.com/kubelet-serving-ca=cluster.

• Vérifiez que les étiquettes sont définies à l’aide de la kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca commande.

  kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca
  

  La sortie doit afficher l’étiquette kubernetes.azure.com/kubelet-serving-ca avec la valeur cluster de chaque nœud d’agent.

Vérifier que kubelet TLS Bootstrapping fonctionne

• Vérifiez que le processus de démarrage a lieu à l’aide de la kubectl get commande.

  kubectl get csr --field-selector=spec.signerName=kubernetes.io/kubelet-serving
  

  Dans la sortie, toutes les demandes de CSR doivent être dans l’état Approved,Issued, ce qui indique que la demande a été approuvée et qu’un certificat signé a été émis. Les CSR de service ont le nom du kubernetes.io/kubelet-servingsignataire . Par exemple:

  NAME        AGE    SIGNERNAME                                    REQUESTOR                    REQUESTEDDURATION   CONDITION
  csr-1ab2c   113s   kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:uoxr9r      none              Approved,Issued
  csr-defgh   111s   kubernetes.io/kubelet-serving                 system:node:akswinp7000000   none              Approved,Issued
  csr-ij3kl   46m    kubernetes.io/kubelet-serving                 system:node:akswinp6000000   none              Approved,Issued
  csr-mn4op   46m    kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:ho7zyu      none              Approved,Issued
  

Vérifier que kubelet utilise un certificat obtenu à partir du démarrage TLS du serveur

• Vérifiez que kubelet utilise un certificat de service signé par l’autorité de certification de cluster à l’aide de la kubectl debug commande.

  kubectl debug node/<node> -ti --image=mcr.microsoft.com/azurelinux/base/core:3.0 -- ls -l /host/var/lib/kubelet/kubelet-server-current.pem
  

  Si un kubelet-server-current.pem lien symbolique existe, le kubelet a démarré/renouvelé son propre certificat de serveur et l'AC du cluster l'a signé.

Désactiver la rotation des certificats kubelet de service

• Désactivez la rotation des certificats de kubelet en mettant à jour le pool de nœuds à l’aide de la commande az aks nodepool update avec la balise aks-disable-kubelet-serving-certificate-rotation=true.

  az aks nodepool update --cluster-name <cluster-name> --resource-group <resource-group> --name <node-pool-name> --tags aks-disable-kubelet-serving-certificate-rotation=true
  

1. Réimagez vos nœuds à l’aide d’une mise à niveau d'image de nœud ou en mettant à l’échelle le pool sur zéro instances, puis ramenez-les à la valeur souhaitée.

Autorotation de certificat

Gardez à l'esprit les considérations suivantes lors de l'utilisation des rotations automatiques de certificat :

• Si vous disposez d’un cluster existant, vous devez mettre à niveau ce cluster pour activer l’autorotation de certificat.
• Ne désactivez pas le démarrage TLS pour activer l’autorotation du certificat.
• Si le cluster est dans un état arrêté pendant l’autorotation de certificat, seuls les certificats du plan de contrôle sont affectés. Dans ce cas, vous devez recréer le pool de nœuds après la rotation des certificats pour lancer la rotation des certificats du pool de nœuds.
• Pour tous les clusters AKS créés ou mis à niveau après mars 2022, AKS fait pivoter automatiquement les certificats non-CA sur les nœuds du plan de contrôle et de l'agent dans les 80 % de la durée de validité du certificat client avant leur expiration, sans interruption pour le cluster.

Vérifier que le TLS Bootstrapping est activé sur le pool de nœuds de l'agent actuel.

1. Vérifiez que l'amorçage TLS est activé pour votre cluster en accédant à l’un des chemins suivants :

   • Sur un nœud Linux : /var/lib/kubelet/bootstrap-kubeconfig ou /host/var/lib/kubelet/bootstrap-kubeconfig
   • Sur un nœud Windows : C:\k\bootstrap-config

   Pour plus d’informations, consultez Se connecter à des nœuds de cluster Azure Kubernetes Service (AKS) pour la maintenance ou la résolution des problèmes.

   Remarque

   Le chemin d’accès au fichier peut changer à mesure que les versions de Kubernetes évoluent.

2. Une fois qu’une région est configurée, créez un cluster ou mettez à niveau un cluster existant pour définir l’autorotation de certificat pour le certificat de cluster. Vous devez mettre à niveau le plan de contrôle et le pool de nœuds pour activer cette fonctionnalité.

Contenu connexe

• Bonnes pratiques pour la sécurité et les mises à niveau de cluster dans Azure Kubernetes Service (AKS).