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

O kubectl imprime isso depois de “Unable to connect to the server: tls: failed to verify certificate: ”. Para CAs ECDSA, o motivo interno é “x509: ECDSA verification failure” em vez de “crypto/rsa: verification error”; o nome entre aspas é o Common Name da CA.

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

O que significa

O Go encontrou na sua configuração de confiança uma CA cujo nome corresponde ao emissor do certificado do servidor (“kubernetes” em clusters kubeadm), testou essa CA, e a assinatura não passou na verificação com a chave dela. Duas CAs diferentes têm o mesmo nome: a do seu kubeconfig e a que realmente assinou o certificado do servidor de API. É o resultado clássico de recriar um cluster (kubeadm reset e init) mantendo o ~/.kube/config antigo.

Por que acontece

• O cluster foi recriado com o kubeadm

  comum

  O kubeadm init gera uma nova CA chamada “kubernetes” toda vez; o kubeconfig do cluster anterior ainda embute a CA antiga, com o mesmo nome.

• Um ~/.kube/config antigo ou uma entrada antiga em KUBECONFIG

  comum

  Vários clusters locais (kind, minikube, k3d) recriados com o mesmo nome de contexto deixam para trás dados de CA obsoletos.

• A CA do cluster foi rotacionada

  ocasional

  Depois de uma rotação de CA, os clientes que não receberam o novo bundle de CAs falham assim até que o kubeconfig deles seja atualizado.

Como corrigir

1. 1.

   Confirmar que as chaves das CAs são diferentes

   Nomes iguais com hashes de chave pública diferentes provam que o kubeconfig contém a CA de outro 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.

   Usar o kubeconfig do novo cluster

   Depois do kubeadm init, copie /etc/kubernetes/admin.conf (ou gere de novo os kubeconfigs dos usuários) para que a CA embutida corresponda ao novo 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.

   Verificar qual kubeconfig está em vigor

   A variável KUBECONFIG pode listar vários arquivos; vale o primeiro que define o contexto.

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

← Ver toda a base de erros de assinatura