Gérer et faire pivoter des certificats dans Azure Kubernetes Service (AKS)

Cet article explique comment gérer et faire pivoter des certificats dans des clusters Azure Kubernetes Service (AKS) pour maintenir une communication sécurisée entre les composants et garantir la conformité.

Prerequisites

  • Azure CLI version 2.0.77 ou ultérieure. Vérifiez votre version à l’aide de la az --version commande. Pour installer ou mettre à niveau, consultez Install Azure CLI.

Vérifier la date d’expiration du certificat de l’autorité de certification du cluster

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

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 VMSS

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.

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"

Vérifier la date d’expiration du certificat de machine virtuelle autonome

Vérifiez la date d’expiration d’une machine virtuelle autonome à l’aide de la az vm run-command invoke commande.

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

Effectuer manuellement la rotation des certificats d’AC 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)

Warning

Le renouvellement de vos certificats à l’aide de az aks rotate-certs recrée tous vos nœuds, groupes identiques de machines virtuelles et disques. Ce processus peut entraîner jusqu’à 30 minutes de temps d’arrêt pour votre cluster AKS. Si la commande échoue avant de terminer, utilisez la az aks show commande pour vérifier l’état du cluster qui affiche la rotation du certificat. 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.

  1. Connectez-vous à votre cluster à l’aide de la commande az aks get-credentials.

    az aks get-credentials --resource-group <resource-group> --name <cluster-name>
    
  2. 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>
    
  3. 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 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")
    

Mettre à jour les kubectl certificats clients

  1. Mettez à jour le certificat client 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
    
  2. Vérifiez que les certificats sont mis à jour à l’aide de la kubectl get commande.

    kubectl get nodes
    

    Note

    Si vous avez des services en cours d’exécution sur AKS, vous devrez peut-être mettre à jour leurs certificats.

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

Vérifier que kubelet passe par le processus de démarrage TLS

Lorsque vous activez cette fonctionnalité, chaque kubelet s’exécutant sur vos nœuds passe par le processus de bootstrap TLS du serveur.

Vérifiez que le processus de démarrage est en cours à l’aide de la kubectl get commande pour obtenir les objets CSR actuels au sein de votre cluster.

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

Toutes les demandes de signature de certificat (CSR) actives sont à l’état Approved,Issued, ce qui indique que la demande de signature de certificat a été approuvée et qu’un certificat signé a été délivré. 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:abcd1e      none              Approved,Issued
csr-defgh   111s   kubernetes.io/kubelet-serving                 system:node:akswinp1000000   none              Approved,Issued
csr-ij3kl   46m    kubernetes.io/kubelet-serving                 system:node:akswinp2000000   none              Approved,Issued
csr-mn4op   46m    kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:ab1cde      none              Approved,Issued

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

Vérifiez si le kubelet du nœud utilise un certificat de service signé par l’autorité de certification du cluster à l’aide de la commande [kubectl debug][kubectl-debug] pour examiner le contenu du répertoire PKI de kubelet.

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 initialise et renouvelle son propre certificat serveur via le processus d’amorçage TLS, et ce certificat est signé par l’autorité de certification du cluster.

Désactiver la rotation des certificats kubelet de service

  1. Désactivez kubelet servant la rotation des certificats en mettant à jour le pool de nœuds à l’aide de la az aks nodepool update commande et en spécifiant 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
    
  2. 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.

Pour plus d’informations sur la sécurité AKS, consultez les articles suivants :