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

Vor dieser Zeile protokolliert kubectl 1.37 außerdem die fehlgeschlagene Discovery-Anfrage an die API als Zeile mit Log-Level error, die „Couldn't get current server API group list“ und denselben TLS-Fehler enthält. Hat die CA in der kubeconfig denselben Namen wie die echte, geht der Text weiter mit „(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

Was der Fehler bedeutet

kubectl prüft das Zertifikat des API-Servers gegen die Cluster-CA, die in deiner kubeconfig hinterlegt ist (certificate-authority oder certificate-authority-data), nicht gegen die öffentlichen Root-Zertifikate des Systems. „Unknown authority“ bedeutet, dass die Kette des ausgelieferten Zertifikats nicht zu dieser CA führt: Die kubeconfig enthält keine CA oder die CA eines anderen Clusters, oder etwas zwischen dir und dem API-Server präsentiert ein eigenes Zertifikat.

Warum der Fehler auftritt

• Der kubeconfig fehlt die CA des Clusters, oder sie enthält die eines anderen Clusters

  häufig

  Von Hand bearbeitete kubeconfigs, zusammengeführte Kontexte, die auf den falschen Cluster-Eintrag zeigen, oder eine Server-URL, die auf einen Load Balancer mit einem anderen Zertifikat umgestellt wurde.

• Ein Proxy mit TLS-Inspektion signiert die Verbindung zum API-Server neu

  häufig

  kubectl verwendet HTTPS_PROXY; Firmenproxys präsentieren ein eigenes Zertifikat, das nicht von der Cluster-CA ausgestellt wurde.

• Der Endpunkt eines verwalteten Clusters hat sich geändert

  gelegentlich

  Neu angelegte EKS-, GKE- oder AKS-Cluster (oder rotierte Cluster-CAs) hinterlassen alte kubeconfig-Einträge mit einer CA, die nicht mehr passt.

So behebst du den Fehler

1. 1.

   CA und Server in deiner kubeconfig ansehen

   Dekodiere certificate-authority-data und vergleiche Subject und Datumsangaben mit dem Aussteller des API-Server-Zertifikats.

   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.

   Richtige Cluster-CA einbetten

   Setze den Cluster-Eintrag mit der CA des Clusters (bei kubeadm /etc/kubernetes/pki/ca.crt) und bette sie in die kubeconfig ein.

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

   kubeconfig für verwaltete Cluster neu erzeugen

   Die CLIs der Cloud-Anbieter schreiben einen frischen Cluster-Eintrag mit dem aktuellen Endpunkt und der aktuellen CA.

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

   Proxy für den API-Server umgehen

   Trage Host oder Netz des API-Servers in NO_PROXY ein, statt die TLS-Prüfung abzuschalten (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

← Gesamte Signaturfehler-Datenbank durchsuchen