Kubernetes: Gagal menarik gambar dengan kesalahan "x509: sertifikat ditandatangani oleh otoritas tidak dikenal"

Saya telah mengajukan pertanyaan di sini: http://stackoverflow.com/q/43150437/969784

Dengan asumsi Anda menggunakan sertifikat yang ditandatangani sendiri, CA Anda masih perlu ditambahkan di penyimpanan kepercayaan lokal Anda meskipun Anda menggunakan --skip-tls-verifikasi.

@tokopedia

• --insecure-skip-tls-verify bukanlah argumen yang valid untuk kubectl create ;
• Sebenarnya x509 error ada di sisi docker . Daemon gagal menarik gambar dari registri yang tidak aman itu. Anda dapat merujuk ke registri buruh pelabuhan yang tidak aman tentang cara mempercayai / melewati keamanan registri.

@dixudx Saya lupa menyebutkannya. Saya menginstal sertifikat server secara global pada node master kubernetes ini dan kemudian memulai kembali layanan buruh pelabuhan yang berjalan di atasnya. Setelah itu saya berhasil menarik gambar itu secara manual menggunakan docker pull 10.78.0.228:5000/monitorms . Sebelumnya saya mendapatkan pesan kesalahan ini saat melakukan penarikan manual gambar itu.

Apakah kesalahan datang karena node Kubernetes belum menginstal sertifikat?

@dixudx Selain itu, kubectl options mencantumkan --insecure-skip-tls-verify sebagai salah satu opsi "global" dan mengatakan bahwa ini dapat diteruskan ke perintah Kubernetes apa pun

--insecure-skip-tls-verify hanya melewatkan verifikasi sertifikat server, bukan registri buruh pelabuhan, sehingga tidak dapat menyelesaikan masalah. Kesalahan berasal dari daemon Docker saat menarik image.

Saya menginstal sertifikat server secara global pada node master kubernetes ini dan kemudian memulai kembali layanan buruh pelabuhan yang berjalan di atasnya.

Mungkin Anda harus mencoba perintah docker pull 10.78.0.228:5000/monitorms pada node k8s yang menyimpan pod, bukan master k8s.

Itu adalah argumen yang valid untuk kubectl create tetapi hanya mengontrol kepercayaan antara kubectl dan server API

Galat tarik adalah antara node dan registri buruh pelabuhan. Node perlu memercayai sertifikat atau memperlakukan registri itu sebagai registri tidak tepercaya (yang membuat simpul mentolerir kesalahan verifikasi TLS)

@supereagle Saya akan menambahkan opsi registri tidak aman ke file konfigurasi buruh pelabuhan pada node k8s. Mudah-mudahan itu bisa berhasil

Anda akan berpikir bahwa ini sudah diselesaikan sekarang.

Sertifikat CA

Kasus terekam aktual untuk mencegah akses tidak sah: NOL
Jumlah waktu developer yang terbuang percuma karena perkakas yang tidak mengintegrasikan sertifikat CA ke dalam perkakas mereka dengan benar: jutaan jam kerja.

Pesan moral dalam cerita. Sertifikat CA parit. Sungguh menyebalkan setiap kali Anda mencoba mendapatkan perkakas untuk bekerja sama. Tidak ada yang tahu cara kerjanya. Tak seorangpun. Perangkat lunak yang menggunakannya tidak pernah berfungsi. Pada akhirnya, Anda cukup menyalin semua sertifikat ke setiap mesin dan pemanggang roti agar Anda tidak mendapatkan x509: sertifikat yang ditandatangani oleh otoritas yang tidak dikenal, kesalahan omong kosong setiap kali Anda mencoba melakukan perkakas.

Sekarang saya harus pergi dan mengebor langsung ke inti cluster ini untuk mendapatkan sertifikat itu diinstal, karena rahasia kubernetes untuk menangani buruh pelabuhan sama sekali tidak berguna.

Cukup gunakan uang yang akan dihabiskan untuk mencoba mendapatkan sertifikat CA berdarah untuk bekerja dan menyewa antek dengan kapak yang memotong garis keras ketika peretas datang. CA ini menyatakan bukan keamanan jika tidak mengizinkan orang yang berwenang masuk karena seluruh bidang hanya satu BUG raksasa yang akan membuat JAM perkakas Anda.

/ sig auth

jika ada orang yang menghadapinya saat menggunakan gcr.io secara langsung, satu kemungkinan situasi adalah bahwa sertifikat CA di komputer Anda terlalu tua.

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 '

solusi yang berhasil untuk saya di RH / CentOS:

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

cc @ kubernetes / sig-node-bugs untuk masalah penarikan gambar

jika Anda membuka node yang dimaksud dan mencoba curl -v https://gcr.io/v1/_ping , apakah Anda melihat respons yang berhasil? jika demikian, maka mungkin ada masalah dengan cara node menarik gambar. jika tidak, maka Anda hanya perlu memperbarui sertifikat root pada node tersebut

Ada pembaruan tentang masalah ini? ini menghantam kita sekarang.

@ sross-table

Sejauh yang saya ingat ini adalah masalah buruh pelabuhan, bukan kubernetes. Docker tidak menggunakan sertifikat ca linux. Tidak ada yang tahu kenapa.

Anda harus menginstal sertifikat tersebut secara manual (pada setiap node yang dapat menelurkan pod tersebut) sehingga pekerja galangan dapat menggunakannya:

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

Ini adalah masalah yang sangat menjengkelkan karena Anda harus memotong node Anda setelah bootstrap untuk mendapatkan sertifikat tersebut di sana. Dan kubernetes memunculkan node sepanjang waktu. Bagaimana masalah ini belum diselesaikan adalah misteri bagi saya. Ini IMO showstopper lengkap.

Ini benar-benar harus diselesaikan menggunakan mekanisme rahasia kubernetes. Tapi entah kenapa tidak. Siapa tahu!?

@pompomJuice , mungkinkah ini masalah gambar minikube? Saya bahkan tidak dapat menggulung situs ini

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

Persis maksud saya. Kesalahan curl itu salah. Ini memberi tahu Anda bahwa Anda memiliki sertifikat tetapi sertifikat itu ditandatangani sendiri. Saya rasa itu sangat tidak mungkin. (Kecuali jika Anda meretasnya di sana entah bagaimana)

Itu berarti bahwa pesan kesalahan itu salah. Ini berhubungan dengan poin saya sebelumnya bahwa hampir tidak ada yang mengimplementasikan hal ini dengan benar.

Coba perbarui sertifikat di kotak itu seperti Telusur Ulang yang disarankan di atas.

Saya mengalami masalah yang sama. Sertifikat berasal dari digicert, kubernetes cluster yang berjalan di GCE, sertifikat diinstal melalui host dan dimasukkan ke /etc/docker/certs.d/, dan masih ada kesalahan x509.

Log Docker:
TLS handshake error from XXXXXXXXXX: remote error: tls: bad certificate

Versi Kub:
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"}

tuan rumah:
NAME = "Ubuntu"
VERSI = "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

Silakan paste seluruh nama folder di '/etc/docker/certs.d/'. Dan nama file sertifikat tersebut.

Ini harus berfungsi jika semua node Anda memiliki sertifikat yang terpasang.

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

Sejauh ini hanya ada satu node di cluster :)

Ubah itu menjadi ca.crt dan client.key

Seperti di sini: https://docs.docker.com/engine/security/certificates/#creating -the-client-certificate

Mengubahnya menjadi ca.crt dan ca.key baik di direktori, serta memperbarui file yang dipanggil dalam rahasia. Saya memulai kembali layanan buruh pelabuhan pada node dan menerapkan ulang pod dan masih, kesalahan yang sama.

Berikut info lebih lanjut dari curl:

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

• Mencoba XXX.XXX.XXX.XXX ...
• TCP_NODELAY disetel
• Terhubung ke foo.bar.com (XXX.XXX.XXX.XXX) port 5000 (# 0)
• ALPN, menawarkan h2
• ALPN, menawarkan http / 1.1
• Pilihan sandi: PROFILE = SYSTEM
• berhasil menetapkan lokasi verifikasi sertifikat:
• CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: tidak ada
• TLSv1.2 (KELUAR), Jabat tangan TLS, Klien halo (1):
• TLSv1.2 (IN), TLS handshake, Server hello (2):
• TLSv1.2 (IN), TLS jabat tangan, Sertifikat (11):
• TLSv1.2 (KELUAR), peringatan TLS, Server halo (2):
• Masalah sertifikat SSL: tidak bisa mendapatkan sertifikat penerbit lokal
• hentikan aliran jeda!
• Menutup koneksi 0
  curl: (60) Masalah sertifikat SSL: tidak bisa mendapatkan sertifikat penerbit lokal
  Detail selengkapnya ada di sini: https://curl.haxx.se/docs/sslcerts.html

curl melakukan verifikasi sertifikat SSL secara default, menggunakan "bundel"
dari kunci publik Otoritas Sertifikat (CA) (sertifikat CA). Jika default
file bundel tidak memadai, Anda dapat menentukan file alternatif
menggunakan opsi --cacert.
Jika server HTTPS ini menggunakan sertifikat yang ditandatangani oleh CA yang diwakili dalam
bundel, verifikasi sertifikat mungkin gagal karena a
masalah dengan sertifikat (mungkin kedaluwarsa, atau namanya mungkin
tidak cocok dengan nama domain di URL).
Jika Anda ingin menonaktifkan verifikasi sertifikat curl, gunakan
opsi -k (atau --insecure).
HTTPS-proxy memiliki opsi serupa --proxy-cacert dan --proxy-insecure.

Saya membuat kesalahan, yang seharusnya client.key bukan ca.key .

Ini harus berhasil.

Periksa dua kali dengan mencoba memulai gambar secara manual di kotak.

Tampaknya itu juga tidak berhasil :( kesalahan yang sama

Apa yang terjadi saat Anda mencoba memulai penampung buruh pelabuhan secara manual dari baris perintah?

haruskah saya menggunakan kubectl run di salah satu node atau menjalankan docker? buruh pelabuhan dijalankan, kontainer mulai tetapi saya mendapatkan koneksi ditolak. Jika saya menggunakan kubctl, error: failed to discover supported resources: an error on the server ("") has prevented the request from succeeding

Jika saya menggunakan kubectl di mesin lokal saya yang memanfaatkan kubectl proxy, container akan dimulai tetapi saya mendapatkan yang berikut ini:
http: server memberikan respons HTTP ke klien HTTPS

perintah kubectl: kubectl run --image = registry: 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_TLS_KEY = / certs /client.key "--expose = true

Coba berikut ini.

Buat registri buruh pelabuhan Anda sendiri. Gunakan gitlab untuk ini gratis.

Host beberapa gambar di http. Cobalah untuk memulai pod dengan gambar ini. Kemudian verifikasi bahwa buruh pelabuhan yang Anda lihat sebenarnya menjalankan pod itu. Jika ya maka Anda tahu Anda memiliki simpul yang benar.

Kemudian seperti sebelumnya docker run dan jelaskan kepada saya apa yang Anda maksud dengan koneksi ditolak.

Masalah menjadi basi setelah 90d tidak ada aktivitas.
Tandai terbitan sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup basi

Masalah basi membusuk setelah 30 hari tidak aktif.
Tandai terbitan sebagai baru dengan /remove-lifecycle rotten .
Masalah busuk ditutup setelah 30 hari tambahan tidak aktif.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup busuk
/ remove-lifecycle basi

Masalah busuk ditutup setelah 30 hari tidak aktif.
Buka kembali masalah dengan /reopen .
Tandai terbitan sebagai baru dengan /remove-lifecycle rotten .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/Menutup

Jadi apa solusi / perbaikannya? Saya masih mendapatkannya setelah meningkatkan dari 3.9 menjadi 3.10. Gagal menarik gambar "docker-registry.default. Svc: 5000 / openshift / mysql @ sha256 : dfd9f18f47caf290 ... dan dengan errormessage: v2 /: x509: sertifikat ditandatangani oleh otoritas tak dikenal. Saya setuju dengan @pompomJuice. Perbaikan permanen yang tidak rusak setelah pemasangan / peningkatan diperlukan atau rancang ulang ini sepenuhnya. Jika tidak, ini belum siap untuk beban kerja produksi.

solusi yang berfungsi untuk menarik gambar buruh pelabuhan di ubuntu dari Artifactory (sertifikat ditandatangani sendiri):

• letakkan semua yang digunakan (jika ada lebih dari satu root ca) sertifikat ca di / usr / local / share / ca-certificate
• jalankan update-ca-certificate
• restart daemon buruh pelabuhan (sudo service docker restart)

jika ada orang yang menghadapinya saat menggunakan gcr.io secara langsung, satu kemungkinan situasi adalah bahwa sertifikat CA di komputer Anda terlalu tua.

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 '

solusi yang berhasil untuk saya di RH / CentOS:

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

Ini benar-benar berhasil untuk saya.

Saya menjalankan kubernetes di RancherOS sebagai bagian dari pengaturan Rancher 2.x dan memiliki registri pribadi yang tidak terhubung ke internet, jadi saya harus menggunakan sertifikat yang ditandatangani sendiri di atasnya, yang mengakibatkan kesalahan x509. Saya membaca utas ini dan beberapa lainnya dan memecahkan masalah - berbagi seandainya itu dapat membantu seseorang, jika tidak secara langsung maka dengan menyarankan jalur yang mungkin.

Ini berhasil untuk saya - https://www.ctrl-alt-del.cc/2018/11/solution-rancher-2-k8s-private-registry.html

2020 dan masih masalah yang sama.
registri pelabuhan pribadi.
buruh pelabuhan bekerja tanpa masalah.
ls /etc/docker/certs.d/registry.myharbor.com/ menampilkan sertifikat.
kubernetes gagal menarik gambar dengan kesalahan imagepullbackoff.
Sudah 3 tahun dan kubernetes masih memiliki masalah ini. Sangat mengecewakan.

Terpecahkan

1. Pastikan Anda dapat melakukan docker pull IMAGENAME dari mesin tempat Anda menjalankan penerapan (file yaml, paket helm, dll.,)
2. Pada semua node kubernetes pastikan yang berikut ini ada /etc/docker/certs.d/my-private-registry.com/my-private-registry.com.crt

Saya bekerja di lingkungan pengembang lokal saya

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

Saya menggunakan Jfrog Container Registry sebagai registri untuk minikube saya. Saya bisa melakukan hal berikut:

1. docker login localhost: 443 | atau | ip- tambahkan: 443
2. docker push ip- add: 443 / docker-local / test : terbaru
3. docker pull ip- add: 443 / docker-local / test : terbaru

Saya telah mengkonfigurasi Jfrog Container Registry untuk berjalan di belakang Nginx Reverse Proxy mendengarkan pada port 443. Membuat sertifikat yang ditandatangani sendiri dan Jfrog menggunakan sertifikat ini.

Pekerja galangan dikonfigurasi untuk menggunakan sertifikat yang ditandatangani sendiri sebagai berikut.

1. Buat sertifikat, salin ke / usr / local / share / ca-certificate /
2. sudo update-ca-sertifikat
3. salin sertifikat ke /etc/docker/cert.d/192.168.0.114:443/ca.crt
4. restart buruh pelabuhan, pastikan saja

Konfigurasi K8 untuk menggunakan rahasia login buruh pelabuhan dengan file .yaml sebagai berikut:

1. base64 menyandikan ~ / .docker / config.json
2. gunakan di template berikut
   apiVersion: v1 kind: Secret metadata: name: myregistrykey namespace: awesomeapps data: .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== type: kubernetes.io/dockerconfigjson

Di deployment.yaml, saya menggunakan ImagePullSecrets dan flag name.

Sekarang setelah semua pengaturan ini di mana buruh pelabuhan bekerja di terminal, saya mendapatkan kesalahan pada pod mengatakan x509 IP Sans.

Saya memeriksa banyak dokumentasi dan masalah K8, meniru langkah https://github.com/kubernetes/kubernetes/issues/43924#issuecomment -631533150

mereplikasi langkah-langkah itu tidak berhasil. Adakah yang bisa memberi tahu saya apa yang saya lakukan salah? dan bagaimana saya bisa memperbaikinya.

Saya juga mengalami masalah yang sama, tetapi pada EKS dalam kasus ini. Saya menggunakan daemonset untuk menyebarkan beban kerja yang memiliki hak istimewa untuk mencoba perbaikan di atas pada semua node untuk memecahkan masalah ini (gambar ada di registri yang ditandatangani pribadi).