Rotation des certificats dans Azure Kubernetes Service (AKS)
Article
Azure Kubernetes Service (AKS) utilise des certificats pour l’authentification avec un grand nombre de ses composants. Les clusters avec contrôle d’accès en fonction du rôle Azure (Azure RBAC) qui ont été créés après mars 2022 sont activés avec la rotation automatique des certificats. Vous pouvez être amené à procéder à une rotation périodique de ces certificats pour des raisons de sécurité ou de stratégie. Par exemple, une stratégie peut demander une rotation de l’ensemble de vos certificats tous les 90 jours.
Notes
La rotation automatique des certificats est activée par défaut uniquement pour les clusters AKS compatibles RBAC.
Cet article vous montre comment fonctionne la rotation des certificats dans votre cluster AKS.
Avant de commencer
Cet article nécessite la version 2.0.77 ou ultérieure d’Azure CLI. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
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 ».
Le serveur d’API dispose d’une autorité de certification de cluster, qui signe les certificats pour la communication unidirectionnelle, du serveur d’API vers les kubelets.
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 utilise un jeton de compte de service que l’autorité de certification de 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.
Notes
Les clusters AKS créés avant le mois de mai 2019 possèdent des certificats qui expirent au bout de deux ans.
Les clusters AKS créés après le mois de mai 2019 possèdent des certificats qui expirent au bout de 30 ans.
Vous pouvez vérifier quand votre cluster a été créé à l’aide de la commande kubectl get nodes, qui vous indique l’âge de vos pools de nœuds.
Vérifier les 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.
Vérifier la date d’expiration du certificat de nœud de l’agent VMAS
Vérifiez la date d’expiration du certificat de nœud de l’agent VMAS à l’aide de la commande az vm run-command invoke.
az vm run-command invoke --resource-group MC_rg_myAKSCluster_region --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 de nœud de l’agent de groupe de machines virtuelles identiques
Vérifiez la date d’expiration du certificat de nœud de l’agent de groupe de machines virtuelles identiques à l’aide de la commande az vmss run-command invoke.
Pour qu’AKS assure automatiquement la rotation des certificats autres que les certificats d’autorité de certification, le cluster doit bénéficier du démarrage TLS activé par défaut dans toutes les régions Azure.
Notes
Si vous avez un cluster existant, vous devez mettre à niveau ce cluster pour activer la rotation automatique des certificats.
Ne désactivez pas le démarrage pour que la rotation automatique reste activée.
Si le cluster est dans un état arrêté pendant la rotation automatique des certificats, 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, Azure Kubernetes Service effectue une rotation automatique des certificats non CA sur les nœuds du plan de contrôle et de l’agent dans les 80 % du délai valide du certificat client, avant qu’ils n’expirent sans temps d’arrêt pour le cluster.
Comment vérifier si le pool de nœuds de l’agent actuel est activé pour le démarrage TLS ?
Vérifiez si le démarrage TLS est activé sur votre cluster en accédant à l’un des chemins d’accès suivants :
Sur un nœud Linux : /var/lib/kubelet/bootstrap-kubeconfig ou /host/var/lib/kubelet/bootstrap-kubeconfig
Le chemin du fichier peut changer à mesure que les versions de Kubernetes évoluent.
Une fois qu’une région est configurée, créez un cluster ou mettez à niveau un cluster existant pour configurer ce cluster pour la rotation automatique des certificats de cluster. Vous devez mettre à niveau le plan de contrôle et le pool de nœuds pour activer cette fonctionnalité.
Procéder à la rotation manuelle de vos certificats de cluster
Avertissement
La rotation de vos certificats à l’aide de az aks rotate-certs recrée tous vos nœuds, le groupe identique de machines virtuelles et les disques, et peut entraîner jusqu’à 30 minutes d’interruption pour votre cluster AKS.
az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME
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 --name $CLUSTER_NAME
Important
L’exécution de az aks rotate-certs peut prendre jusqu’à 30 minutes. Si la commande échoue avant de se terminer, utilisez az aks show pour vérifier que l’état du cluster est Certificate Rotating (Rotation de certificat en cours). Si le cluster est dans l’état d’échec, réexécutez az aks rotate-certs pour procéder de nouveau à la rotation de vos certificats.
Vérifiez que les anciens certificats ne sont plus valides à l’aide d’une commande kubectl, telle que kubectl get nodes.
kubectl get nodes
Si vous n’avez pas mis à jour les certificats utilisés par kubectl, vous voyez une erreur similaire à l’exemple 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")
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 --name $CLUSTER_NAME --overwrite-existing
Vérifiez que les certificats ont été mis à jour à l’aide de la commande kubectl get.
kubectl get nodes
Notes
Si vous avez des services en cours d'exécution sur AKS, vous devrez peut-être mettre à jour leurs certificats.
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
Commentaires sur Azure Kubernetes Service
Azure Kubernetes Service est un projet open source. Sélectionnez un lien pour fournir des commentaires :