x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

kubectl l’affiche après « Unable to connect to the server: tls: failed to verify certificate: ». Pour les AC ECDSA, la cause interne est « x509: ECDSA verification failure » au lieu de « crypto/rsa: verification error » ; le nom entre guillemets est le nom commun de l’AC.

kubectl and other Go clients — a CA with the right name but the wrong key (e.g. a kubeconfig from before kubeadm reset)

Ce que cela signifie

Go a trouvé dans votre configuration de confiance une AC dont le nom correspond à l’émetteur du certificat du serveur (« kubernetes » dans les clusters kubeadm), l’a essayée, et la signature ne s’est pas vérifiée avec la clé de cette AC. Deux AC différentes portent le même nom : celle de votre kubeconfig et celle qui a réellement signé le certificat du serveur d’API. C’est la conséquence classique d’une reconstruction de cluster (kubeadm reset puis init) en conservant l’ancien ~/.kube/config.

Pourquoi cela se produit

• Le cluster a été recréé avec kubeadm

  fréquente

  kubeadm init génère à chaque fois une nouvelle AC nommée « kubernetes » ; le kubeconfig du cluster précédent contient toujours l’ancienne AC du même nom.

• Un ancien ~/.kube/config ou une ancienne entrée de KUBECONFIG

  fréquente

  Plusieurs clusters locaux (kind, minikube, k3d) recréés sous le même nom de contexte laissent derrière eux des données d’AC périmées.

• L’AC du cluster a fait l’objet d’une rotation

  occasionnelle

  Après une rotation de l’AC, les clients qui n’ont pas reçu le nouveau fichier d’AC échouent de cette façon jusqu’à la mise à jour de leur kubeconfig.

Comment corriger l’erreur

1. 1.

   Confirmer que les clés des AC diffèrent

   Des noms identiques avec des empreintes de clé publique différentes prouvent que le kubeconfig contient l’AC d’un autre cluster.

   # Same name, different key? Compare the public keys of the two CAs
   kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' \
     | base64 -d | openssl x509 -noout -pubkey | openssl sha256
   sudo openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -pubkey | openssl sha256   # on a control-plane node

2. 2.

   Utiliser le kubeconfig du nouveau cluster

   Après kubeadm init, copiez /etc/kubernetes/admin.conf (ou régénérez les kubeconfig des utilisateurs) pour que l’AC intégrée corresponde au nouveau cluster.

   # After kubeadm init/reset: replace the old kubeconfig with the new admin.conf
   mkdir -p "$HOME/.kube"
   sudo cp /etc/kubernetes/admin.conf "$HOME/.kube/config"
   sudo chown "$(id -u):$(id -g)" "$HOME/.kube/config"

3. 3.

   Vérifier quel kubeconfig est réellement utilisé

   KUBECONFIG peut lister plusieurs fichiers ; le premier qui définit le contexte l’emporte.

   # Make sure no other kubeconfig overrides it
   echo "$KUBECONFIG"; kubectl config current-context

← Parcourir toute la base de données des erreurs de signature