Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority

Antes de esta línea, kubectl 1.37 también registra la solicitud fallida de descubrimiento de la API como una línea de nivel error que contiene «Couldn't get current server API group list» y el mismo error de TLS. Cuando la CA del kubeconfig tiene el mismo nombre que la real, el texto continúa con «(possibly because of … while trying to verify candidate authority certificate \"kubernetes\")».

kubectl (client-go) — the API server's certificate does not chain to the kubeconfig's certificate-authority-data

Qué significa

kubectl verifica el certificado del servidor de API con la autoridad de certificación (CA) del clúster guardada en tu kubeconfig (certificate-authority o certificate-authority-data), no con las raíces públicas del sistema. «Unknown authority» significa que la cadena del certificado servido no lleva a esa CA: el kubeconfig no tiene CA o tiene la de otro clúster, o algo entre tú y el servidor de API presenta su propio certificado.

Por qué ocurre

• Al kubeconfig le falta la CA del clúster o tiene la de otro clúster

  frecuente

  Archivos kubeconfig editados a mano, contextos combinados que apuntan a la entrada de clúster equivocada, o una URL del servidor cambiada a un balanceador de carga que sirve otro certificado.

• Un proxy que inspecciona TLS vuelve a firmar la conexión con el servidor de API

  frecuente

  kubectl usa HTTPS_PROXY; los proxies corporativos presentan su propio certificado, que la CA del clúster no emitió.

• Cambió el endpoint de un clúster gestionado

  ocasional

  Los clústeres EKS, GKE o AKS recreados (o las CA de clúster rotadas) dejan entradas antiguas en el kubeconfig con una CA que ya no coincide.

Cómo solucionarlo

1. 1.

   Revisar la CA y el servidor de tu kubeconfig

   Decodifica certificate-authority-data y compara su sujeto y sus fechas con el emisor del certificado del servidor de API.

   kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' \
     | base64 -d | openssl x509 -noout -subject -enddate
   kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'

2. 2.

   Incrustar la CA correcta del clúster

   Configura la entrada del clúster con la CA del clúster (en kubeadm, /etc/kubernetes/pki/ca.crt) e incrústala en el kubeconfig.

   # kubeadm clusters: the cluster CA is /etc/kubernetes/pki/ca.crt on a control-plane node
   kubectl config set-cluster my-cluster --server=https://k8s.example.com:6443 \
     --certificate-authority=ca.crt --embed-certs=true

3. 3.

   Volver a generar el kubeconfig de los clústeres gestionados

   Las CLI de los proveedores de nube escriben una entrada de clúster nueva con el endpoint y la CA actuales.

   # Managed clusters: regenerate the kubeconfig entry from the provider
   aws eks update-kubeconfig --name my-cluster --region eu-central-1
   gcloud container clusters get-credentials my-cluster --region europe-west1
   az aks get-credentials --resource-group rg --name my-cluster

4. 4.

   Excluir el servidor de API del proxy

   Añade el host o la red del servidor de API a NO_PROXY en lugar de desactivar la verificación TLS (insecure-skip-tls-verify).

   # kubectl honours HTTPS_PROXY; exclude the API server so a TLS-inspecting proxy is bypassed
   export NO_PROXY=k8s.example.com,10.0.0.0/8

← Explorar toda la base de datos de errores de firma