Kubernetes: Fehler beim Abrufen des Bildes mit dem Fehler "x509: Zertifikat von unbekannter Behörde signiert"

Ich habe die Frage hier gestellt: http://stackoverflow.com/q/43150437/969784

Angenommen, Sie verwenden ein selbstsigniertes Zertifikat, muss Ihre Zertifizierungsstelle auch dann in Ihrem lokalen Vertrauensspeicher hinzugefügt werden, wenn Sie --skip-tls-verify verwenden.

@ Rushilpaul

• Das erste --insecure-skip-tls-verify ist kein gültiges Argument für kubectl create ;
• Tatsächlich ist x509 error auf der Seite von docker . Der Daemon konnte kein Image aus dieser unsicheren Registrierung abrufen. Informationen zum Vertrauen / Überspringen der Registrierungssicherheit finden Sie in der

@dixudx Ich habe vergessen, es zu erwähnen. Ich habe das Serverzertifikat global auf diesem Kubernetes-Masterknoten installiert und dann den darauf ausgeführten Docker-Dienst neu gestartet. Danach kann ich das Bild erfolgreich manuell mit docker pull 10.78.0.228:5000/monitorms . Vorher habe ich diese Fehlermeldung erhalten, als ich das Bild manuell gezogen habe.

Kommt der Fehler, weil auf den Kubernetes-Knoten das Zertifikat nicht installiert ist?

@dixudx Außerdem listet kubectl options --insecure-skip-tls-verify als eine der "globalen" Optionen auf und sagt, dass es an jeden Kubernetes-Befehl übergeben werden kann

--insecure-skip-tls-verify überspringt nur die Zertifikatüberprüfung des Servers und nicht die Docker-Registrierung, sodass das Problem nicht gelöst werden kann. Der Fehler stammt vom Docker-Daemon beim Abrufen des Bildes.

Ich habe das Serverzertifikat global auf diesem Kubernetes-Masterknoten installiert und dann den darauf ausgeführten Docker-Dienst neu gestartet.

Vielleicht sollten Sie den Befehl docker pull 10.78.0.228:5000/monitorms auf den k8s-Knoten versuchen, die den Pod enthalten, nicht auf dem k8s-Master.

Dies ist ein gültiges Argument für kubectl create , steuert jedoch nur das Vertrauen zwischen kubectl und dem API-Server

Der Pull-Fehler liegt zwischen dem Knoten und der Docker-Registrierung. Der Knoten muss entweder dem Zertifikat vertrauen oder diese Registrierung als nicht vertrauenswürdige Registrierung behandeln (wodurch der Knoten TLS-Überprüfungsfehler toleriert).

@supereagle Ich werde die unsichere Registrierungsoption zur Docker-Konfigurationsdatei auf den k8s-Knoten hinzufügen. Hoffentlich sollte das den Trick machen

Sie würden denken, dass dies jetzt gelöst ist.

CA-Zertifikate

Tatsächlich aufgezeichnete Fälle zur Verhinderung des unbefugten Zugriffs: NULL
Unzählige Entwicklerzeit wird durch Werkzeuge verschwendet, die CA-Zertifikate nicht ordnungsgemäß in ihre Werkzeuge integrieren: Gasmillionen von Arbeitsstunden.

Moral der Geschichte. Graben CA Zertifikate. Solch ein Ballache jedes Mal, wenn Sie versuchen, Werkzeuge zum Zusammenarbeiten zu bringen. Niemand weiß, wie es funktioniert. Niemand. Software, die es verwendet, funktioniert nie. Am Ende kopieren Sie einfach alle Zertifikate auf jede Maschine und Ihren Toaster, damit Sie nicht jedes Mal, wenn Sie versuchen, ein Werkzeug zu machen, diesen verdammten x509: Zertifikat erhalten, das von einem Bullshit-Fehler einer

Jetzt muss ich bis zum Kern dieses Clusters bohren, um diese Zertifikate zu installieren, da die Geheimnisse von kubernetes für den Umgang mit Docker einfach nutzlos sind.

Verwenden Sie einfach das Geld, das ausgegeben worden wäre, um die blutigen CA-Zertifikate zum Laufen zu bringen, und stellen Sie einen Handlanger mit einer Axt ein, die die Hardlines schneidet, wenn der Hacker kommt. Diese Zertifizierungsstelle bestätigt, dass dies keine Sicherheit ist, wenn keine autorisierten Personen zugelassen werden, da das gesamte Feld nur ein riesiger Fehler ist, der Ihre Werkzeuge blockiert.

/ sig auth

Sollte sich jemand bei der direkten Verwendung von gcr.io damit auseinandersetzen, besteht eine mögliche Situation darin, dass CA-Zertifikate auf Ihrem Computer zu alt sind.

docker pull gcr.io/google_containers/kube-apiserver-amd64:v1.7.2
Trying to pull repository gcr.io/google_containers/kube-apiserver-amd64 ...
Get https://gcr.io/v1/_ping: x509: certificate signed by unknown authority '

Lösung, die für mich unter RH / CentOS funktioniert hat:

yum check-update ca-certificates; (($?==100)) && yum update ca-certificates || yum reinstall ca-certificates
update-ca-trust extract

cc @ kubernetes / sig-node-bugs für das Problem beim Abrufen von Bildern

Wenn Sie zu dem betreffenden Knoten gehen und curl -v https://gcr.io/v1/_ping versuchen, sehen Sie eine erfolgreiche Antwort? Wenn ja, liegt möglicherweise ein Problem mit der Art und Weise vor, wie der Knoten die Bilder abruft. Wenn nicht, müssen Sie lediglich die Stammzertifikate auf diesem Knoten aktualisieren

Gibt es ein Update zu diesem Thema? das trifft uns jetzt.

@ Srossross-Tableau

Soweit ich mich erinnere, war dies ein Docker-Problem, kein Kubernetes-Problem. Docker verwendet keine Linux-Zertifikate. Niemand weiß warum.

Sie müssen diese Zertifikate manuell installieren (auf jedem Knoten, der diese Pods erzeugen könnte), damit Docker sie verwenden kann:

/etc/docker/certs.d/mydomain.com:1234/ca.crt

Dies ist ein äußerst ärgerliches Problem, da Sie Ihre Knoten nach dem Bootstrapping abschlachten müssen, um diese Zertifikate dort zu erhalten. Und Kubernetes erzeugt ständig Knoten. Wie dieses Problem noch nicht gelöst wurde, ist mir ein Rätsel. Es ist ein kompletter Showstopper IMO.

Dies sollte wirklich mit dem Geheimmechanismus von Kubernetes gelöst werden. Aber irgendwie ist es nicht. Wer weiß!?

@pompomJuice , könnte dies ein Minikube-Image-Problem sein? Ich kann diese Seite nicht einmal kräuseln

minikube ssh -- curl -I https://storage.googleapis.com
curl: (60) SSL certificate problem: self signed certificate in certificate chain

$minikube logs
...
Nov 08 18:19:06 minikube localkube[3032]: E1108 18:19:06.788101    3032 remote_image.go:108] PullImage "gcr.io/google_containers/heapster:v1.3.0" from image service failed: rpc error: code = 2 desc = error pulling image configuration: Get https://storage.googleapis.com/artifacts.google-containers.appspot.com/containers/images/sha256:f9d33bedfed3f1533f734a73718c15976fbd37f04f383087f35e5ebd91b18d1e: x509: certificate signed by unknown authority
..

Genau mein Standpunkt. Dieser Lockenfehler ist einfach falsch. Es sagt Ihnen, dass Sie die Zertifikate haben, aber sie sind selbst signiert. Ich finde das höchst unwahrscheinlich. (Es sei denn, Sie haben sie dort irgendwie gehackt)

Das bedeutet, dass diese Fehlermeldung einfach falsch ist. Dies hängt mit meinem vorherigen Punkt zusammen, dass fast niemand dieses Zeug richtig umsetzt.

Versuchen Sie, die Zertifikate auf dieser Box wie oben vorgeschlagen ReSearchITEng zu aktualisieren.

Ich habe das gleiche Problem. Zertifikate stammen von Digicert, Kubernetes-Cluster, die in GCE ausgeführt werden, Zertifikate, die über den Host installiert und in /etc/docker/certs.d/ abgelegt wurden, und weiterhin x509-Fehler.

Docker-Protokolle:
TLS handshake error from XXXXXXXXXX: remote error: tls: bad certificate

Kub Version:
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState:"clean", BuildDate:"2017-11-20T05:28:34Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Gastgeber:
NAME = "Ubuntu"
VERSION = "16.04.3 LTS (Xenial Xerus)"
ID = Ubuntu
ID_LIKE = debian
PRETTY_NAME = "Ubuntu 16.04.3 LTS"
VERSION_ID = "16.04"
HOME_URL = " http://www.ubuntu.com/ "
SUPPORT_URL = " http://help.ubuntu.com/ "
BUG_REPORT_URL = " http://bugs.launchpad.net/ubuntu/ "
VERSION_CODENAME = xenial
UBUNTU_CODENAME = xenial

Fügen Sie bitte den gesamten Ordnernamen in '/etc/docker/certs.d/' ein. Und die Dateinamen der Zertifikate.

Es sollte funktionieren, wenn auf allen Knoten dieses Zertifikat installiert ist.

root @ kubernetes-minion-group-96k7 : /etc/docker/certs.d/ "foo.bar.com": 5000 # ll
insgesamt 16
drwxr-xr-x 2 root root 4096 2. Dezember 20:43 ./
drwxr-xr-x 3 root root 4096 2. Dezember 20:07 ../
-rw-r - r-- 1 root root 3332 2. Dezember 20:23 domain.crt
-rw-r - r-- 1 root root 1675 2. Dezember 20:43 domain.key

Bisher nur ein Knoten im Cluster :)

Ändern Sie diese in ca.crt und client.key

Wie hier: https://docs.docker.com/engine/security/certificates/#creating -the-client-certificates

Sie wurden sowohl im Verzeichnis in ca.crt als auch in ca.key geändert und die im Geheimen aufgerufenen Dateien aktualisiert. Ich habe den Docker-Dienst auf dem Knoten neu gestartet und die Pods erneut bereitgestellt und trotzdem denselben Fehler.

Hier sind weitere Informationen von Curl:

curl -vvI https://foo.bar.com : 5000 / v2 /

• Versuch XXX.XXX.XXX.XXX ...
• TCP_NODELAY gesetzt
• Verbunden mit foo.bar.com (XXX.XXX.XXX.XXX) Port 5000 (# 0)
• ALPN bietet h2 an
• ALPN bietet http / 1.1 an
• Auswahl der Verschlüsselung: PROFIL = SYSTEM
• Festlegen der Speicherorte für die Zertifikatüberprüfung:
• CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: keine
• TLSv1.2 (OUT), TLS-Handshake, Client-Hallo (1):
• TLSv1.2 (IN), TLS-Handshake, Server Hallo (2):
• TLSv1.2 (IN), TLS-Handshake, Zertifikat (11):
• TLSv1.2 (OUT), TLS-Warnung, Server Hallo (2):
• Problem mit dem SSL-Zertifikat: Lokales Ausstellerzertifikat kann nicht abgerufen werden
• hat den Pausenstrom gestoppt!
• Verbindung schließen 0
  Curl: (60) Problem mit dem SSL-Zertifikat: Lokales Ausstellerzertifikat kann nicht abgerufen werden
  Weitere Details hier: https://curl.haxx.se/docs/sslcerts.html

curl führt standardmäßig eine Überprüfung des SSL-Zertifikats mithilfe eines "Bundles" durch.
der öffentlichen Schlüssel der Zertifizierungsstelle (CA) (CA-Zertifikate). Wenn die Standardeinstellung
Bundle-Datei ist nicht ausreichend, Sie können eine alternative Datei angeben
Verwenden Sie die Option --cacert.
Wenn dieser HTTPS-Server ein Zertifikat verwendet, das von einer in dargestellten Zertifizierungsstelle signiert ist
Im Bundle ist die Zertifikatsüberprüfung wahrscheinlich aufgrund von a fehlgeschlagen
Problem mit dem Zertifikat (es ist möglicherweise abgelaufen oder der Name ist möglicherweise abgelaufen
nicht mit dem Domainnamen in der URL übereinstimmen).
Wenn Sie die Überprüfung des Zertifikats durch curl deaktivieren möchten, verwenden Sie
die Option -k (oder --insecure).
HTTPS-Proxy hat ähnliche Optionen --proxy-cacert und --proxy-unsicher.

Ich habe einen Fehler gemacht, der sollte client.key sein, nicht ca.key .

Es sollte funktionieren.

Überprüfen Sie dies noch einmal, indem Sie versuchen, das Bild manuell auf dem Feld zu starten.

Das schien auch nicht zu funktionieren :( gleicher Fehler

Was passiert, wenn Sie versuchen, den Docker-Container manuell über die Befehlszeile zu starten?

sollte ich kubectl run auf einem der knoten oder docker run verwenden? Docker laufen, der Container startet, aber ich bekomme die Verbindung abgelehnt. Wenn ich kubctl benutze, error: failed to discover supported resources: an error on the server ("") has prevented the request from succeeding

Wenn ich kubectl auf meinem lokalen Computer verwendet habe, der den kubectl-Proxy nutzt, wird der Container gestartet, aber ich erhalte Folgendes:
http: server gab HTTP-Antwort an HTTPS-Client

Befehl kubectl: kubectl run --image = Registrierung: 2 devreg-test2 --port = 5000 --env = "DOMAIN = Cluster, REGISTRY_HTTP_ADDR = 0.0.0.0: 5000, REGISTRY_HTTP_TLS_CERTIFICATE = / certs / ca.crt, REGISTRY_HTTP_LT_ /client.key "--expose = true

Versuche Folgendes.

Erstellen Sie Ihre eigene Docker-Registrierung. Verwenden Sie gitlab dafür ist es kostenlos.

Hosten Sie einige Bilder auf http. Versuchen Sie, einen Pod mit diesem Bild zu starten. Stellen Sie dann sicher, dass der Docker, den Sie sich ansehen, tatsächlich diesen Pod ausführt. Wenn ja, wissen Sie, dass Sie den richtigen Knoten haben.

Dann wie vor docker run und erkläre mir, was du mit abgelehnter Verbindung meinst.

Probleme sind nach 90 Tagen Inaktivität veraltet.
Markieren Sie das Problem mit /remove-lifecycle stale als frisch.
Veraltete Probleme verrotten nach weiteren 30 Tagen Inaktivität und schließen schließlich.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes / test-infra und / oder fejta .
/ Lebenszyklus abgestanden

Veraltete Probleme verrotten nach 30 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle rotten als frisch.
Faule Probleme werden nach weiteren 30 Tagen Inaktivität geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes / test-infra und / oder fejta .
/ Lebenszyklus faul
/ remove-lifecycle veraltet

Faule Probleme schließen nach 30 Tagen Inaktivität.
Öffnen Sie das Problem erneut mit /reopen .
Markieren Sie das Problem mit /remove-lifecycle rotten als frisch.

Senden Sie Feedback an sig-testing, kubernetes / test-infra und / oder fejta .
/schließen

Was ist die Problemumgehung / Lösung für dieses Problem? Ich bekomme es immer noch nach dem Upgrade von 3.9 auf 3.10. Fehler beim Abrufen des Bilds "docker-registry.default. SVC: 5000 / openshift / mysql @ sha256 : dfd9f18f47caf290 ... und mit Fehlermeldung: v2 /: x509: Zertifikat von unbekannter Behörde signiert. Ich stimme @pompomJuice zu. Eine dauerhafte Korrektur, die bricht nicht ab, nachdem Installation / Upgrades erforderlich sind, oder überarbeitet dies vollständig. Wenn nicht, ist dies nicht für Produktions-Workloads bereit.

Arbeitslösung zum Abrufen des Docker-Images auf Ubuntu aus Artifactory (Zertifikat ist selbst signiert):

• Legen Sie alle verwendeten (wenn es mehr als eine Root-Ca gibt) Zertifikate in / usr / local / share / ca-Zertifikate
• Führen Sie update-ca-certificates aus
• Docker-Daemon neu starten (Sudo Service Docker-Neustart)

Sollte sich jemand bei der direkten Verwendung von gcr.io damit auseinandersetzen, besteht eine mögliche Situation darin, dass CA-Zertifikate auf Ihrem Computer zu alt sind.

docker pull gcr.io/google_containers/kube-apiserver-amd64:v1.7.2
Trying to pull repository gcr.io/google_containers/kube-apiserver-amd64 ...
Get https://gcr.io/v1/_ping: x509: certificate signed by unknown authority '

Lösung, die für mich unter RH / CentOS funktioniert hat:

yum check-update ca-certificates; (($?==100)) && yum update ca-certificates || yum reinstall ca-certificates
update-ca-trust extract

Das hat bei mir tatsächlich funktioniert.

Ich führe Kubernetes unter RancherOS als Teil des Rancher 2.x-Setups aus und habe eine private Registrierung, die nicht mit dem Internet verbunden ist. Daher muss ich ein selbstsigniertes Zertifikat verwenden, was zu einem x509-Fehler führt. Ich habe diesen Thread und einige andere gelesen und das Problem gelöst - Teilen, falls es jemandem helfen kann, wenn nicht direkt, dann indem ich einen möglichen Weg vorschlage.

Dies funktionierte für mich - https://www.ctrl-alt-del.cc/2018/11/solution-rancher-2-k8s-private-registry.html

2020 und immer noch das gleiche Thema.
privates Hafenregister.
Docker Pull funktioniert ohne Probleme.
ls /etc/docker/certs.d/registry.myharbor.com/ zeigt das Zertifikat an.
kubernetes kann keine Bilder mit dem Imagepullbackoff-Fehler abrufen.
Es ist 3 Jahre und kubernetes hat immer noch dieses Problem. Sehr enttäuschend.

Gelöst

1. Stellen Sie sicher, dass Sie auf dem Computer, auf dem Sie die Bereitstellungen ausführen (Yaml-Dateien, Steuerpakete usw.), ein docker pull IMAGENAME ausführen können.
2. Stellen Sie auf allen Kubernetes-Knoten sicher, dass Folgendes vorhanden ist: /etc/docker/certs.d/my-private-registry.com/my-private-registry.com.crt

Ich arbeite in meiner lokalen Entwicklungsumgebung

    OS:
       Ubuntu (bionic) 18.0.4 LTS    
    Minikube Version:
       v1.11.0
    Docker Version:
       19.03.10

Ich verwende Jfrog Container Registry als Registrierung für meinen Minikube. Ich kann Folgendes tun:

1. Docker-Login localhost: 443 | oder | IP- Add: 443
2. Docker Push IP- Add: 443 / Docker-Local / Test : Neueste
3. Docker Pull IP- Add: 443 / Docker-Local / Test : Neueste

Ich habe die Jfrog-Container-Registrierung so konfiguriert, dass sie hinter Nginx Reverse Proxy ausgeführt wird und Port 443 überwacht. Selbstsignierte Zertifikate wurden erstellt, und Jfrog verwendet diese Zertifikate.

Konfigurierter Docker für die Verwendung der selbstsignierten Zertifikate wie folgt.

1. Erstellen Sie Zertifikate, kopieren Sie sie nach / usr / local / share / ca-certificates /
2. sudo update-ca-zertifikate
3. Kopieren Sie das Zertifikat nach /etc/docker/cert.d/192.168.0.114:443/ca.crt
4. Starten Sie den Docker neu

Konfigurieren Sie K8 so, dass das Docker-Anmeldegeheimnis der .yaml-Datei wie folgt verwendet wird:

1. base64 codiert ~ / .docker / config.json
2. Verwenden Sie es in der folgenden Vorlage
   apiVersion: v1 kind: Secret metadata: name: myregistrykey namespace: awesomeapps data: .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== type: kubernetes.io/dockerconfigjson

In der Datei deploy.yaml verwende ich ImagePullSecrets und das Namensflag.

Nach all dem Setup, bei dem der Docker-Pull am Terminal funktioniert, wird auf den Pods eine Fehlermeldung mit der Meldung x509 IP Sans angezeigt.

Ich habe viele Dokumentations- und K8-Probleme durchgearbeitet und den Schritt von https://github.com/kubernetes/kubernetes/issues/43924#issuecomment -631533150 wiederholt

repliziert die Schritte hat nicht geklappt. Kann mich jemand wissen lassen, was ich falsch mache? und wie kann ich das korrigieren?

Ich habe auch die gleichen Probleme, aber auf EKS in diesem Fall. Ich verwende ein Daemonset, um eine privilegierte Workload bereitzustellen und die oben genannten Korrekturen auf allen Knoten zu versuchen, um dieses Problem zu lösen (Images befinden sich in einer privat signierten Registrierung).