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

kubectl выводит это сообщение после «Unable to connect to the server: tls: failed to verify certificate: ». Для CA с ключами ECDSA внутренняя причина звучит как «x509: ECDSA verification failure», а не «crypto/rsa: verification error»; имя в кавычках — общее имя (CN) этого CA.

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

Что это означает

Go нашёл в ваших настройках доверия CA, имя которого совпадает с издателем сертификата сервера («kubernetes» в кластерах kubeadm), попробовал его, и подпись не прошла проверку ключом этого CA. У двух разных CA одно и то же имя: у того, что в kubeconfig, и у того, который на самом деле подписал сертификат API-сервера. Это классический результат пересборки кластера (kubeadm reset и init) с сохранением старого ~/.kube/config.

Почему это происходит

• Кластер пересоздан с помощью kubeadm

  часто

  kubeadm init каждый раз генерирует новый CA с именем «kubernetes»; в kubeconfig от предыдущего кластера по-прежнему встроен старый CA с тем же именем.

• Старый файл конфигурации ~/.kube/config или запись в KUBECONFIG

  часто

  Несколько локальных кластеров (kind, minikube, k3d), пересозданных под одним и тем же именем контекста, оставляют после себя устаревшие данные CA.

• Проведена ротация CA кластера

  иногда

  После ротации CA клиенты, которым не выдали новый пакет сертификатов CA, получают эту ошибку, пока их kubeconfig не обновят.

Как исправить

1. 1.

   Убедитесь, что ключи CA разные

   Одинаковые имена при разных хешах открытых ключей доказывают, что в kubeconfig лежит CA другого кластера.

   # 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.

   Используйте kubeconfig нового кластера

   После kubeadm init скопируйте /etc/kubernetes/admin.conf (или заново сгенерируйте kubeconfig пользователей), чтобы встроенный CA соответствовал новому кластеру.

   # 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.

   Проверьте, какой kubeconfig действует

   В KUBECONFIG может быть указано несколько файлов; используется первый, в котором определён контекст.

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

← Открыть всю базу ошибок подписей