Moby: --insecure-registry harus di "docker pull"

Kami menjalankan registry buruh pelabuhan internal yang tidak aman di semua CI dan lingkungan produksi. Saya harus mengatakan bahwa akan sangat berguna untuk hanya mengaktifkan akses ke semua pendaftar yang tidak aman tanpa harus mencantumkannya satu per satu. Kami memiliki beberapa pendaftar di setiap lingkungan untuk HA. Perubahan ini telah membuat segalanya menjadi lebih rumit bagi kami. Saya akan membuka tiket masalah lain yang khusus untuk mengatasinya, karena masalah ini lebih untuk memindahkan opsi ke tarik daripada di daemon.

Dan ada sedikit masalah ayam dan telur ketika Anda tidak menggunakan port tetap untuk menjalankan registri.

Karena Anda tidak tahu port mana yang akan ditetapkan oleh buruh pelabuhan sebelumnya, Anda tidak dapat benar-benar memulai demo dengan bendera yang mereferensikannya.

:+1:

jadi saya kira mendukung --insecure pada baris perintah docker pull , dengan paksa menonaktifkan pemeriksaan keamanan, jelas untuk perintah _this_ pull, juga akan menyelesaikan masalah Anda @proppy dan @octalthorpe kan? karena berjalan dengan bendera ini tidak akan memeriksa daftar apa pun

@abourget itu juga perlu didukung di API jarak jauh.

Saat ini docker-py mengekspos flag insecure_registry pada fungsi pull , tetapi itu hanya digunakan untuk menyelesaikan titik akhir: https://github.com/docker/docker-py/blob/master/ buruh pelabuhan/klien.py#L794

Pelakunya tampaknya https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6

Tetapi saya tidak dapat menemukan PR atau masalah yang sesuai di mana perubahan itu dibahas.

@tiborvass ada ide?

@proppy - Ini ditangani sebagai kerentanan keamanan yang diembargo dan tidak dibahas dalam PR publik. Tim inti memiliki visibilitas dan suara tentang masalah ini.

Saya perlu merenungkan implikasi dari perubahan seperti itu untuk localhost/127.0.0.1, tetapi saya tidak terlalu tertarik dengan hal itu. Ini adalah konfigurasi yang tidak standar dan tidak umum dan solusinya didokumentasikan dengan baik.

@ewindisch di sisi lain ada banyak daemon buruh pelabuhan yang sudah berjalan, dengan wadah registri berjalan di localhost .

Jika benar-benar semua pengguna itu harus melewati --insecure-registry localhost:5000 , Anda sebaiknya menjadikannya default.

@ewindisch Apakah kalian memiliki dokumentasi atau panduan untuk apa yang merupakan kerentanan kelas embargo? Ini bukan RCE jarak jauh dan tidak diautentikasi. Bahaya di sini tampaknya tidak cukup akut untuk membenarkan perubahan besar dalam rilis poin tanpa peringatan.

@mmdriley - definisi menurut Mitre/NST umumnya berlaku. Dalam hal ini, serangan man-in-the-middle dapat dilakukan yang memungkinkan eksekusi kode yang tidak dapat dipercaya secara arbitrer pada sistem yang terpengaruh, jadi ya, kami mengklasifikasikan ini sebagai RCE. Ini berarti bahwa jika Anda menggunakan Docker untuk mengambil gambar di laptop di kafe, misalnya, pengguna lain dari titik akses WiFi tersebut berpotensi menjalankan aplikasi sewenang-wenang yang disediakan oleh penyerang. Mereka juga berpotensi mendapatkan akses ke akun DockerHub Anda atau pendaftar lain yang akan Anda autentikasi.

EDIT: menambahkan tautan untuk deskripsi CVE: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

Ya, saya salah mengatakan ini bukan RCE. Ini adalah bug yang buruk, dan bukti bagus mengapa penandatanganan gambar yang kuat adalah ide yang bagus. Namun, eksploitasi tidak sepele: itu membutuhkan penyerang aktif untuk nongkrong di Starbucks berharap seseorang di dekatnya akan menggunakan Docker melalui WiFi yang tidak aman. Ini tidak akan dipersenjatai dalam semalam -- dan oleh karena itu tidak pantas perubahan yang tidak kompatibel dengan tanpa peringatan.

Seperti yang telah disarankan di atas, ada cara yang jelas untuk meningkatkan keamanan dengan segera tanpa merusak kompatibilitas. Misalnya, menonaktifkan fallback HTTPS untuk index.docker.io dan beberapa pendaftar publik populer lainnya akan secara efektif memecahkan masalah bagi sebagian besar pengguna. Menambahkan peringatan ke output konsol bahwa terjadi fallback HTTP akan mengurangi kasus interaktif. Penggantian HTTP akan ditandai tidak digunakan lagi dan dihapus, katakanlah, pada rilis bulan depan. Terakhir, localhost dan ::1 jelas tidak rentan.

Sekali lagi, saya seharusnya tidak mengabaikan tingkat kerentanan, tetapi saya khawatir bahwa proses respons dan perbaikannya tidak memberikan nilai yang cukup untuk tidak melanggar pelanggan.

Kami saat ini membuat/menghancurkan registry buruh pelabuhan secara dinamis di lingkungan yang tidak memiliki FQDN yang tersedia untuk banyak instance ini. Mendukung opsi --insecure-repository untuk permintaan terkait registri (melalui API jarak jauh) akan menghilangkan komplikasi signifikan yang telah dibuat oleh perbaikan keamanan ini untuk kami.

Kami memiliki masalah serupa dengan Docker 1.3.1. Kami menggunakan registry Docker lokal (private) pada alamat http://docker :5000/. Hingga Docker 1.3.0 berfungsi dengan baik. Dengan Docker versi 1.3.1 itu tidak berfungsi lagi karena klien Docker secara otomatis menganggap Registry dapat dijangkau di HTTPS. Tapi kami tidak menggunakan HTTPS sama sekali.

Akan lebih baik untuk menerapkan mekanisme fallback yang menggunakan HTTP jika server Docker Registry tidak dapat diakses melalui HTTPS.

@kruxik jika Anda menggunakan --insecure-registry docker:5000 saat memulai daemon, itu akan mundur ke HTTP.

@tiborvass terima kasih atas sarannya. Anda benar. Tetapi jika Anda memiliki banyak pengembang dengan workstation dan notebook mereka, menyetel --insecure-registry di setiap stasiun adalah cara yang tidak praktis. Setidaknya biarkan itu sebagai parameter opsional untuk operasi tarik/dorong akan cukup bagi kami;)

+1

Ini bekerja untuk kami dengan 1.3.0, tetapi dengan 1.3.1

versi buruh pelabuhan
....
Versi server: 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> ....Jika registri pribadi ini hanya mendukung HTTP atau HTTPS dengan sertifikat CA yang tidak dikenal, tambahkan --insecure-registry 10.121.4.236:5000 ke argumen daemon. Dalam kasus HTTPS, jika Anda memiliki akses ke sertifikat CA registri, tidak perlu bendera; cukup letakkan sertifikat CA di

Turunkan versi
Versi server: 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> unggahan kontainer tanpa masalah.

Untuk orang lain yang mengalami masalah dengan 1.3.0 hingga 1.3.1, saya harus membuat perubahan berikut untuk OS X dengan boot2docker:

$ boot2docker delete #removes old image
$ rm -f ~/.ssh/id_boot2docker* # remove old keys
$ boot2docker init #generates new keys, cert
$ boot2docker up
$ boot2docker ssh
$ # add EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>" 
$ # to /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart

maka Anda _harus_ dapat melakukan tarikan buruh pelabuhan.

Jika menggunakan ara, Anda juga membutuhkan Fig 1.0.1 dan lakukan:

$ fig up --allow-insecure-ssl

@mhamrah Terima kasih! Menghabiskan berjam-jam mencoba untuk memperbaiki ini...

+1 untuk mengasumsikan localhost aman. Apakah ada yang benar-benar menentang ini?

Ya, dengan asumsi localhost aman akan banyak membantu. saya menggunakan gelandangan untuk kotak buruh pelabuhan saya, jadi memperbarui skrip init setiap kali saya menghancurkan atau membuka kotak tidak efisien. Saya kira saya sekarang harus membuat kotak buruh pelabuhan saya menjadi boneka sehingga saya dapat memodifikasi init pada gelandangan ke atas.

juga menggunakan flag --insecure pada tarik dan dorong akan menyenangkan sehingga saya bisa menggunakan IP kotak gelandangan jika diperlukan.

@thocking : dengan asumsi localhost aman: silakan lihat https://github.com/docker/docker/issues/8898

Sejujurnya saya juga bertanya-tanya mengapa Jenkins Containerbuilds otomatis saya gagal dalam mendorong ...
(Bagus untuk memiliki testenv. sebelum memasukkannya ke produksi).
Saya harus memeriksa apakah "fitur" ini benar-benar diumumkan - jika tidak, saya akan lebih paranoid pada perubahan besar yang sangat ekstrem pada perilaku daemon.

Apa yang saya lewatkan dalam diskusi ini:
Mengapa saya bahkan harus memberi tahu daemon untuk menggunakan mode aman / tidak aman "default" untuk setiap Host?

Bukankah lebih produktif untuk mengatur registri dengan perilaku default ini?
Jadi tergantung pada pengaturan jika tidak ada parameter --secure atau --insecure yang diberikan, daemon harus meminta
jika cara aman dimungkinkan dan jika tidak, mundur ke tidak aman digunakan.

Salah satu hal utama dari buruh pelabuhan adalah sangat mudah digunakan dan untuk mengatur env. tolong jangan bunuh efek WOW ini dengan "rilis / keputusan" seperti itu ...

hanya 2 sen saya ...

Masalah serupa di sini dengan yang di atas termasuk @jwthomp. Saya telah menghabiskan 10+ jam mencoba menyelesaikan masalah ini dan sementara itu telah diturunkan ke buruh pelabuhan 1.3.0.

Saya menjalankan registri buruh pelabuhan di bawah Marathon dan registri buruh pelabuhan saat ini "mendukung SSL dengan menjalankan nginx sebagai frontend" (lihat https://github.com/docker/docker-registry/issues/697 ) tetapi menggunakan nginx sebagai frontend adalah diperumit oleh Marathon yang menjalankan registri buruh pelabuhan di berbagai host/port budak.

Saya dapat mengaktifkan SSL langsung di dalam registri (menggunakan GUNICORN_OPTS) tetapi kemudian _only_ berbicara SSL dan tidak dapat lulus pemeriksaan kesehatan Marathon.

Saya telah memodifikasi sistem konfigurasi Bamboo HAProxy untuk juga mengonfigurasi HAProxy sebagai frontend https untuk semua layanan seperti yang dilakukan nginx, tetapi saya masih memiliki masalah dengan buruh pelabuhan yang memvalidasi sertifikat pada registri pribadi saya, jadi itu masih tidak cocok saya saat ini.

Semuanya sangat baik untuk melindungi dari RCE tetapi juga perlu ada kompatibilitas ke belakang. Setidaknya tanda untuk daemon buruh pelabuhan untuk menentukan semua registri sebagai tidak aman. Harus ada cara untuk menentukan http atau https sebagai bagian dari nama registri di setiap perintah docker pull. Saat ini, 1.3.1 tampak seperti Catch-22 besar bagi siapa saja yang menggunakan registri pribadi.

@mhamrah https://github.com/boot2docker/boot2docker/pull/630

Bagus.
Pada Jum, 14 Nov 2014 jam 10:42 Ilya Radchenko [email protected]
menulis:

@mhamrah https://github.com/mhamrah boot2docker/boot2docker#630
https://github.com/boot2docker/boot2docker/pull/630

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63082089.

@mhamrah Saya tidak perlu menghapus kunci ssh, dll. Saya baru saja menambahkan baris yang diperlukan di /var/lib/boot2docker/profile dan memulai ulang buruh pelabuhan. Terima kasih atas tipnya!

Dingin. Saya mengalami kesulitan bahkan ssh'ing, saya kira karena beberapa versi
ketidakcocokan antara docker iso. Saya benar-benar beralih menggunakan gelandangan +
coreos untuk dukungan buruh pelabuhan, dan berfungsi dengan baik. Anda hanya perlu mengatur
DOCKER_HOST, yang dilakukan boot2docker secara otomatis.

Pada Kamis 20 Nov 2014 pukul 1:52:21 Kayvan Sylvan [email protected]
menulis:

@mhamrah https://github.com/mhamrah Saya tidak perlu menghapus
kunci ssh, dll. Saya baru saja menambahkan baris yang diperlukan di
/var/lib/boot2docker/profile dan restart buruh pelabuhan. Terima kasih atas tipnya!

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63768043.

Maaf guys, saya bermaksud untuk menanggapi sebelumnya.

Seperti yang sudah dikatakan @ewindisch , kami tidak ingin mendorong perilaku sisi klien ini. Rasa sakit yang disebabkan oleh membutuhkan bendera sebagai bendera daemon, adalah agar orang benar-benar mengatur TLS di registri mereka. Kalau tidak, tidak ada insentif. Terima kasih atas pengertian Anda.

Ada gambar berbasis buruh pelabuhan "resmi" dari registri buruh pelabuhan di registri buruh pelabuhan resmi. Penggunaan yang disarankan adalah tanpa TLS.

Jika Docker ingin pengguna mengatur TLS di registri mereka, apakah tidak masuk akal untuk menyeimbangkan "rasa sakit yang disebabkan" dengan "pengurangan rasa sakit" yang sama dan berlawanan dengan memberikan gambar buruh pelabuhan resmi yang secara default menyediakan TLS?

@tiborvass . Anda mengabaikan kasus dev di balik firewall internal. Jadi sekarang saya harus mengatur proxy terbalik dengan SSL diaktifkan di depan registri saya (tidak ada alasan untuk melakukan ini) atau saya harus pergi ke masing-masing dan setiap pengembang saya dan memodifikasi argumen ke daemon yang berjalan di dalam boot2docker. Ini tidak masuk akal. Ada banyak lingkungan dev yang menyediakan keamanan yang dapat dikonfigurasi di mana keamanan sering dinonaktifkan untuk lingkungan dev. Saya terkejut melihat Anda menutup masalah ini ketika ada begitu banyak suara untuk solusi.

Bagaimana dengan memasukkan semua ip pribadi ke daftar putih? Jalan tengah?

Atau membuat nama protokol, 'http' atau 'https' bagian dari nama gambar untuk tarik.

@tiborvass baik @sroebuck dan @blevine membuat poin yang bagus. Ini akan semakin menjadi skenario bagi toko-toko yang membangun kontainer di rumah, dan kemarahan karena melanggar alur kerja sebelumnya juga akan meningkat. Kita semua memahami sisi keamanan dari hal ini, dan mungkin pull bukanlah tempat yang tepat untuk menyelesaikannya, tetapi selama gambar registri resmi tidak menyediakan cara yang sederhana dan tidak biasa untuk menangani perubahan ini, seharusnya dianggap sebagai masalah UX yang cukup penting untuk dipecahkan.

Hai @tiborvass ! Masalah ini menggigit kita sekarang juga. Saya lebih suka pendekatan @nickandrew . Akan sedikit lebih seperti git clone dan juga membuka kemungkinan protokol pluggable yang berbeda di masa depan. Kemenangan bagi buruh pelabuhan karena akan mengurangi kopling dan kemenangan bagi komunitas.

@blevine perhatikan bahwa pada 1.3.2 localhost daftar putih secara default, lihat: https://github.com/docker/docker/pull/9124

Anda dapat membuat registri mendengarkan di localhost dengan meneruskan: -p 127.0.0.0:5000:5000 ke docker run

@proppy , saya tidak yakin bagaimana mendengarkan di localhost membantu saya.

docker pull {http}myregistry.domain.com/myapp:latest

Atau haruskah itu menjadi URL yang sebenarnya? Saya tidak tahu apa-apa tentang protokol registri tetapi tampaknya tidak kompatibel untuk memperluas sintaks saat ini untuk menentukan URL yang tepat.

@blevine itu berarti Anda dapat mengatur registri mirroring lokal.

Arg, sekarang saya harus mendekodekan base64 cloud-config saya untuk coreos agar mesin saya dapat memulai

@tiborvass Wow, ini sangat disayangkan. :(

Kami memiliki kluster pengembangan yang kami bawa naik dan turun dengan cepat dan bagian dari cara kami menangani kluster ini adalah kami membuat registri untuk kluster itu. Sebuah cluster dapat berupa banyak node fisik atau vms, dan juga dapat berada di mesin desktop atau laptop pengembang (walaupun kami biasanya tidak dapat meluncurkan tumpukan penuh). Setiap cluster adalah tumpukan mandiri dan lingkungan pengembangan. Kami juga memiliki alat baris perintah berbasis buruh pelabuhan yang memungkinkan pengembang berinteraksi dengan pengaturan cluster pengembangan apa pun di perusahaan.

Dalam lingkungan yang kompleks dan dinamis semacam ini, menjadikan TLS pada registri sebagai persyaratan adalah rasa sakit yang luar biasa. Harus memodifikasi startup daemon buruh pelabuhan setiap kali kami menyiapkan, kami menambahkan jaringan baru tempat registri dapat berada sama-sama menyusahkan.

Jangan salah paham, saya menghargai pemikiran di balik keinginan untuk mendukung TLS secara eksklusif, namun saya mendorong Anda untuk mempertimbangkan bahwa ada kasus yang valid di mana lingkungan dengan aman mendukung penghapusan kompleksitas TLS untuk pengurangan rasa sakit dan infrastruktur yang diperlukan untuk mendukung dia.

@tiborvass +1. +1000. Ini telah menghasilkan kompleksitas yang sama sekali tidak perlu untuk
kami ke alur kerja pengembangan yang sangat dinamis. Hambatan untuk masuk telah
dibesarkan secara signifikan di sini untuk sesuatu yang hanya perlu diterapkan di a
konteks produksi. Tolong akhiri rasa sakit kami.

Pada Selasa, Desember 9, 2014, Jeff Thompson [email protected]
menulis:

@tiborvass https://github.com/tiborvass Wow, ini salah satunya
meja virtual membalik momen sedih. :(

Kami memiliki kluster pengembangan yang kami bawa naik dan turun dengan cepat dan sebagian
cara kami menangani klaster ini adalah dengan membuat registri untuk klaster tersebut. A
cluster bisa berupa banyak node fisik atau vms, dan bisa juga di a
pengembang mesin desktop atau laptop (meskipun kami biasanya tidak dapat meluncurkan a
tumpukan penuh). Setiap cluster adalah tumpukan dan pengembangan yang sepenuhnya mandiri
lingkungan. Kami juga memiliki alat baris perintah berbasis buruh pelabuhan yang memungkinkan a
pengembang untuk berinteraksi dengan pengaturan cluster pengembangan apa pun di perusahaan.

Dalam lingkungan yang kompleks dan dinamis semacam ini, membuat TLS di registri
persyaratannya adalah rasa sakit yang luar biasa. Harus memodifikasi startup daemon buruh pelabuhan
setiap kali kami menyiapkan, kami menambahkan jaringan baru tempat registri berada
sama-sama sakit.

Jangan salah paham, saya menghargai pemikiran di balik keinginan untuk mendukung
TLS, namun ada kasus di mana lingkungan dengan aman mendukung penghapusan
kompleksitas TLS untuk pengurangan rasa sakit dan infrastruktur yang dibutuhkan
untuk mendukungnya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/8887#issuecomment -66367681.

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

Bukankah --insecure-registry 0.0.0.0/8 menyelesaikan masalah Anda? Dengan begitu Anda masih bisa menggunakan HTTP.

Notasi CIDR ini dapat digunakan secara lebih terperinci untuk mengaktifkan konfigurasi "di belakang firewall" dengan menetapkan rentang seperti "--insecure-registry 172.16.0.0/12". Saya tidak menyarankan menggunakan opsi ini sama sekali, tetapi saya menyarankan agar pengguna memilih opsi ini untuk menggunakan rentang yang lebih selektif (seperti ruang IP mereka) daripada semua alamat mungkin dengan 0.0.0.0/8.

Daemon buruh pelabuhan dibangun ke dalam coreos, jadi saya harus menambahkan flag-flag itu ke startup di seluruh cluster. Saya pikir itu jauh lebih fleksibel untuk memilikinya pada perintah tarik untuk lingkungan di mana Anda tidak dapat mengontrol daemon buruh pelabuhan itu sendiri.

Ini sama dengan memberi tahu kita untuk mengubah file php.ini untuk host php bersama.

Pada 9 Desember 2014, pukul 22:18, Tibor Vass [email protected] menulis:

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

Tidakkah --insecure-registry 0.0.0.0/8 menyelesaikan masalah Anda? Dengan begitu Anda masih bisa menggunakan HTTP.

—
Balas email ini secara langsung atau lihat di GitHub.

@mattwilliamson Execution flags dapat dikonfigurasi dengan CoreOS. Anda dapat mengedit file konfigurasi systemd untuk Docker. Untuk mengonfigurasi ini untuk sebuah cluster, Anda dapat menggunakan cloud-config.

Contoh perubahan konfigurasi Docker ada di situs web CoreOS. Seseorang dapat dengan mudah memodifikasi instruksi untuk menambahkan flag debug untuk menentukan flag register tidak aman sebagai gantinya.

https://coreos.com/docs/launching-containers/building/customizing-docker/

@tiborvass seluruh ekosistem konfigurasi perlu mendukung ini agar dapat bekerja dengan mudah di luar kotak. Orang-orang tidak mengharapkan untuk membuat penyesuaian yang tidak standar ke startup daemon di mana pun mereka mungkin menarik (boot2docker, coreos, apa pun yang diinstal dengan modul chef/boneka, dll) ketika mereka pindah ke langkah menyiapkan registri internal mereka sendiri. Gambar wadah registri resmi itu sendiri _tidak lagi berfungsi_ saat menggunakan langkah-langkah yang ditandai "disarankan" di file readme. Readme tidak menyebutkan TLS sama sekali, dan pengaturan ini adalah proses yang tidak sepele. Selain itu, seperti @mattwilliamson disebutkan secara singkat di atas, ada banyak kasus seperti lingkungan pembangunan bersama di mana seseorang yang menggunakan daemon untuk menarik gambar tidak sama dengan orang yang mengonfigurasi daemon.

Intinya adalah menjadikan ini sebagai argumen sisi klien jelas merupakan solusi yang tidak terlalu mengganggu, dan yang lebih penting, solusi yang tidak terlalu menentukan. Docker telah menjadi primitif dalam lusinan jika bukan ratusan proyek dan alur kerja lain, dan karena itu seharusnya tidak mendikte pola penggunaan pada lingkup ini. Hanya karena Git menawarkan opsi konfigurasi runtime sederhana untuk menonaktifkan http.sslverify tidak berarti Linus Torvalds mendorong orang untuk tidak mengamankan data sensitif mereka dalam konteks yang penting untuk dilakukan.

Analogi git adalah contoh yang baik tentang bagaimana ini seharusnya bekerja. Git tidak memaksa Anda untuk menggunakan TLS, dan itu adalah keputusan pengguna saat menyiapkan host level apa yang ingin mereka dukung. Ini juga merupakan keputusan pengguna saat menarik tingkat keamanan apa yang mereka butuhkan (atau ingin dilewati). Konfigurasi adalah langkah sederhana, baik secara global atau per repo. Meskipun Docker tidak memaksa kita untuk menggunakan TLS, dengan membuat alternatif non-sepele, tidak memberikan pilihan lain yang masuk akal.

Notasi CIDR memungkinkan pendekatan "palu berat" yang bisa dibilang, dan AFAIK, tidak memetakan ke nama dns, jadi meskipun saya menutupi 10.0.0.0/16, menarik some.private-registry.com dalam 10.0/16 won' t bekerja. Lebih penting lagi, konfigurasi tidak sepele.

Docker berkembang pesat dalam kesederhanaannya untuk containerisasi, dan sangat mengurangi hambatan untuk menerapkan aplikasi di berbagai lingkungan. Kita semua tahu manfaatnya. Sebagian besar pengembang tidak dapat menjawab pertanyaan notasi CIDR sederhana, file konfigurasi buruh pelabuhan mungkin berada di tempat yang tidak standar (lokasi boot2docker dan CoreOS keduanya berbeda dari distro lain), dan cukup mudah untuk mengacaukan file konfigurasi ini dengan loop umpan balik yang sulit untuk kesuksesan. Saya harus membuntuti syslog? Oh tunggu aku di RHEL dan itu pesan?

Pengembang baru dapat dengan mudah menyalin dan menempelkan cuplikan docker pull , tetapi memasukkannya ssh ke host boot2docker, menjalankan vi, mengedit file konfigurasi, lalu mengekor syslog untuk kesalahan... tidak terlalu banyak. Dan oh ya, Anda lupa me-restart daemon buruh pelabuhan.

Inilah yang ingin saya lihat:

• Pengaturan daemon Docker diterapkan melalui perintah docker
• Pengaturan tarikan buruh pelabuhan untuk penggantian TLS, ditentukan melalui perintah buruh pelabuhan
• Pengaturan tarikan Docker dipertahankan di seluruh perintah untuk registri tertentu

Ya, tetapi amazon tidak mengizinkan Anda mengubah konfigurasi autoscscale. Saya harus membuat salinannya atau membuat yang baru.

Pada 9 Desember 2014, pukul 23:55, Eric Windisch [email protected] menulis:

Bendera eksekusi dapat dikonfigurasi dengan CoreOS. Anda dapat mengedit file konfigurasi systemd untuk Docker. Untuk mengonfigurasi ini untuk sebuah cluster, Anda dapat menggunakan cloud-config.

Contoh perubahan konfigurasi Docker ada di situs web CoreOS. Seseorang dapat dengan mudah memodifikasi instruksi untuk menambahkan flag debug untuk menentukan flag register tidak aman sebagai gantinya.

https://coreos.com/docs/launching-containers/building/customizing-docker/

—
Balas email ini secara langsung atau lihat di GitHub.

Saat ini saya harus mengatasi masalah ini di lingkungan pengembangan perusahaan saya dengan menjalankan perintah yang diteliti dengan susah payah ini setiap kali saya melakukan 'boot2docker up'

boot2docker ssh 'sudo sh -c "echo \"EXTRA_ARGS=\\\"--insecure-registry 10.0.0.0/8\\\"\" > /var/lib/boot2docker/profile && sudo /etc/init.d/docker restart"'

Apa yang menyakitkan. Adopsi buruh pelabuhan di dalam perusahaan 400+ orang saya terhenti karena masalah ini. Kami sama sekali tidak menggunakan TLS di lingkungan pengembangan internal kami di mana semuanya dikendalikan. Kami memuji penggunaannya untuk repositori hub publik, dan berpikir bahwa memaksa di tempat lain dalam semua kasus adalah kesalahan besar.

@CleanCut diletakkan dengan sangat baik. Sangat kecewa bahwa 1.4.0 datang dan pergi dan masalah ini tetap terbuka.

@CleanCut luar biasa - Apa yang saya inginkan di boot2docker, adalah menambahkan lebih banyak informasi ke payload awal boot2docker init , yang kemudian akan melakukan ini untuk Anda.

tidak menyelesaikan masalah khusus non-vm-based-boot2docker, tetapi --insecure-registry bukan satu-satunya penyesuaian khusus situs yang diinginkan pengguna b2d.

bisakah Anda membuat permintaan tarik atau masalah untuk ini di repo boo2docker?

Benar-benar meningkatkan penghalang bagi seseorang untuk menggunakan proyek yang dipuji karena menurunkan hambatan.

Pada 13 Desember 2014, pukul 02:10, Justin Clayton [email protected] menulis:

@CleanCut diletakkan dengan sangat baik. Sangat kecewa bahwa 1.4.0 datang dan pergi dan masalah ini tetap terbuka.

—
Balas email ini secara langsung atau lihat di GitHub.

@SvenDowideit Tentu saja. Ini dia

Sepertinya ada konsensus di utas ini bahwa ini bukan masalah yang terpecahkan; bisakah kami membuka kembali masalah ini?

Ya silahkan!
Le 2014-12-15 15:05, "Justin Clayton" [email protected] a écrit :

Sepertinya ada konsensus di utas ini bahwa ini tidak terpecahkan
masalah; bisakah kami membuka kembali masalah ini?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/8887#issuecomment -67055878.

+1. Saya tidak punya apa-apa untuk ditambahkan, tetapi hanya ingin melampiaskan frustrasi saya atas keputusan ini. Seperti orang lain, saya menjalankan registri di jaringan lokal di mana keamanan ditangani dan membuat mual di tempat lain. Saya memiliki lusinan wadah buruh pelabuhan yang sekarang perlu dipantulkan untuk menambahkan bendera 'terdokumentasi dengan baik'.

@bfirsh - ini adalah salah satu contoh di mana file konfigurasi daemon Docker dan kill -HUP <dockerdaemonpid> akan luar biasa - memicunya untuk membaca ulang cfg, tanpa perlu memulai ulang - sehingga menghindari wadah-restart

@SvenDowideit +1 untuk fitur reload, sangat menjengkelkan untuk me-restart server dengan konfigurasi sederhana.

+1

Maafkan saya jika saya tidak memahami banyak hal dengan benar, tetapi sepertinya masalah ini adalah akar dari skenario saya sendiri (mirip dengan yang digariskan oleh @blevine di mana perusahaan saya memiliki proxy penulisan ulang sertifikat yang menyebabkan saya tidak dapat bahkan berbicara dengan Docker Hub Registry publik). Saya tahu bahwa pada akhirnya saya akan ingin mengatur registri pribadi saya sendiri, tetapi saya baru dalam tahap belajar, di mana saya belum yakin apakah saya akan mengadopsi Docker. Ini adalah mimpi buruk UX bagi seseorang di tahap awal adopsi.

http://stackoverflow.com/questions/27536180/docker-on-mac-behind-proxy-that-changes-ssl-certificate

+1 untuk membuka kembali diskusi ini, karena sepertinya komunitas tidak terlalu senang dengan solusi saat ini.

https://twitter.com/justinclayton42/status/550143834705780737

hanya mencoba untuk memukul ini dari semua sudut sampai kita mendengar jawaban pasti tentang topik ini.

+1, saat ini sulit untuk dikonfigurasi dan berfungsi.

@mhamrah membuat poin bagus. Jangan memaksakan sesuatu, biarkan pengguna memutuskan dan mengonfigurasi untuk kebutuhan mereka sendiri.

Registri yang menggunakan sertifikat yang ditandatangani sendiri juga menjadi masalah, terutama
dalam konteks pengembang menggunakan boot2docker yang beralih ke file hanya-baca
sistem. Ini membutuhkan langkah konfigurasi tambahan dan berbeda untuk
bootstrap vm yang sedang berjalan.

Saya percaya semua orang yang memposting ke utas ini melihat nilai dan manfaatnya
buruh pelabuhan, menggunakannya setiap hari, mencoba mempromosikannya di
organisasi, tetapi mengalami masalah yang menyakitkan dan tidak perlu yang
menghambat adopsi.

Seperti yang kita semua tahu, buruh pelabuhan masih belum diketahui banyak orang di bidang teknologi.
terutama di dalam perusahaan. Dokumentasi membantu, tetapi kami masih
melompat melalui lingkaran, dan itu adalah penghalang besar dengan keseluruhan negatif
memengaruhi.
Pada Minggu, 25 Januari 2015 pukul 17.54 Jay Taylor [email protected] menulis:

+1, saat ini sulit untuk dikonfigurasi dan berfungsi.

@mhamrah https://github.com/mhamrah membuat poin bagus. Jangan paksa
hal, biarkan pengguna memutuskan dan mengkonfigurasi untuk kebutuhan mereka sendiri.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/8887#issuecomment -71398193.

+1 bagus untuk mencoba berbagai hal dengan cepat

:+1:

:+1:

Sangat mengecewakan bahwa kami masih tidak dapat menarik dari registri yang tidak aman tanpa mengirimkan tanda ke daemon buruh pelabuhan. Ini hanyalah kerumitan lain untuk setiap mesin baru yang kami gunakan.

+1

Beberapa pemikiran:

1. bisakah kita memiliki wildcard nama host? misalnya --insecure-registry=*.internal
2. dapatkah sertifikat yang ditandatangani sendiri diperlakukan berbeda dengan http?
3. terkait dengan 2, dapatkah buruh pelabuhan melakukan sesuatu yang mirip dengan SSH dan meminta pengguna untuk menerima sertifikat yang ditandatangani sendiri setiap kali melihat yang baru/mengeluh dengan keras jika ada yang tidak cocok?

Dan sementara saya membuat saran, mengapa tidak memperlakukan localhost seperti selalu aman? (seperti yang dilakukan Chrome)

Sunting: ah, saya lihat sudah ada.

+1000 untuk ini.. dan +1 pada fitur reload konfigurasi, itulah yang membuat ini dua kali lebih buruk. Saya tetap menggunakan v1.2 karena saya pikir pasti seorang pengelola akan menyadari betapa menjengkelkannya flag --insecure-registry pada daemon untuk penerapan dan memperbaikinya, tetapi entah bagaimana rilis minor tetap mengabaikannya.

Misalnya, jika saya harus mengubah IP registri pribadi saya untuk alasan apa pun, saya harus memulai ulang setiap daemon buruh pelabuhan di setiap VM -- hanya karena registri saya berubah!? 2 hal itu tidak boleh digabungkan dengan erat. Dan memberitahu orang untuk hanya menambahkan 0.0.0.0/8 mengalahkan seluruh tujuan implementasi keamanan di tempat pertama.

Menambahkan flag ini ke perintah push/pull tampaknya sangat jelas sebagai fallback untuk flag daemon, tolong seseorang jelaskan kepada saya mengapa mereka masih melawannya tetapi sementara itu menambahkan fitur "baik untuk dimiliki".

Komentar @agquick tepat, terutama dengan fitur "baik untuk dimiliki".

Menyadari hal ini merupakan masalah yang berkelanjutan bagi sejumlah besar pengguna, kami mempertimbangkan kembali untuk menambahkan --insecure ke pull . @ewindisch dan saya akan mengerjakan PR yang akan kami tautkan ke masalah ini.

Maaf untuk menunggu lama, dan terima kasih telah menyuarakan pendapat Anda dan menunjukkan poin rasa sakit Anda.

@tiborvass Saya bisa membayangkan ada sejumlah besar pengguna yang _tidak_ ingin izinkan menarik dari pendaftar yang tidak aman. Saya menyadari Docker saat ini tidak memiliki kontrol yang halus atas izin/konfigurasi, tetapi jika ada peluang untuk dapat "mengunci" ini, saya pikir itu akan menjadi sentuhan yang bagus.

Oh saya membuatnya begitu! Akan menerapkannya sendiri.

Dikirim dari ponsel cerdas BlackBerry 10 saya di jaringan Bell.
Dari: Sebastiaan van Stijn
Dikirim: Senin, 23 Februari 2015 16:53
Kepada: buruh pelabuhan/ buruh pelabuhan
Balas Ke: buruh pelabuhan/buruh pelabuhan
Cc: Kristopher Cieplak
Subjek: Re: [docker] --insecure-registry harus di "docker pull" (#8887)

@tibor vasshttps://github.com/tiborvass Saya bisa membayangkan ada sejumlah besar pengguna yang tidak ingin mengizinkan penarikan dari pendaftar yang tidak aman. Saya menyadari Docker saat ini tidak memiliki kontrol yang halus atas izin/konfigurasi, tetapi jika ada peluang untuk dapat "mengunci" ini, saya pikir itu akan menjadi sentuhan yang bagus.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/docker/docker/issues/8887#issuecomment -75644600.

@thaJeztah Saya mencoba mencari tahu kasus penggunaan apa yang Anda pikirkan yang berarti kami tidak dapat memiliki --insecure-registry flag ke docker pull .

• jika pengguna tidak ingin secara tidak sengaja MITMed pada registri yang aman, mereka hanya dapat menghindari melewati --insecure-registry
• jika pengguna ingin menerapkan pada pengguna bahwa semua gambar berasal dari registri yang aman (yaitu skenario 'perusahaan'), mereka tidak dapat menerapkannya sama sekali saat ini!

Jadi bisakah Anda menguraikan apa yang dihambat oleh docker pull --insecure-registry ?

Untuk menguraikan poin kedua saya, saya tidak dapat melihat bagaimana Anda akan mengunci ini tanpa memikirkan kembali secara signifikan cara kerja buruh pelabuhan! Mengesampingkan kemampuan docker load tarball yang bisa Anda peroleh dengan menulis registry puller Anda sendiri, dan menggunakan docker run -v untuk mengeskalasi privs dan menambahkan sesuatu ke argumen daemon, ada cara yang sangat sederhana untuk mem-bypass 'pelaksanaan':

$ docker pull registry:5000/aidanhs/blah                                    
FATA[0004] Error: v1 ping attempt failed with error: Get https://registry:5000/v1/_ping: EOF. If this private registry supports only HTTP or HTTPS [...]
$ socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 &
[1] 22924
$ docker pull localhost:5000/aidanhs/blah
Pulling repository localhost:5000/aidanhs/blah
[...]
Status: Image is up to date for localhost:5000/aidanhs/blah:latest
$ docker tag localhost:5000/aidanhs/blah registry:5000/aidanhs/blah

jika pengguna ingin menerapkan pada pengguna bahwa semua gambar berasal dari registri yang aman (yaitu skenario 'perusahaan'), mereka tidak dapat menerapkannya sama sekali saat ini!

Ini skenarionya, ya.

Untuk menguraikan poin kedua saya, saya tidak dapat melihat bagaimana Anda mengunci ini tanpa memikirkan kembali secara signifikan cara kerja buruh pelabuhan

Saya sepenuhnya memahami bahwa (saat ini) tidak ada cara untuk menguncinya. Pengguna yang memiliki akses ke docker.sock memiliki akses root yang efektif, sehingga dapat mengubah apa pun yang mereka suka. Selain itu, mereka masih dapat mengubah flag daemon dan memulai ulang daemon.

Namun, itu _tidak_ memberikan sinyal yang jelas kepada pengguna jika docker pull --insecure-registry .. memberikan kesalahan ("Pendaftaran tidak aman dinonaktifkan"), yang _akan_ memberi tahu pengguna bahwa itu tidak diinginkan, misalnya, ketika mencoba beberapa contoh yang mereka temukan di suatu tempat.

Jadi, apakah itu akan mencakup semua kasus? Tidak. Apakah itu _sakit_, saya juga tidak berpikir begitu.

Saya pribadi merasa itu akan lebih berbahaya daripada kebaikan, hanya karena itu menyesatkan orang untuk berpikir "oh lihat, buruh pelabuhan memberlakukan ini" padahal sebenarnya itu adalah perlindungan yang sangat dangkal. Saya bisa melanjutkan, tetapi pada akhirnya saya pikir itu tergantung pada selera.

Jika Anda mencari tahu bagaimana sakitnya, cukup gulir ke atas. Ada banyak sekali masalah UX dengan pendekatan ini yang menciptakan hambatan untuk adopsi, dan semuanya telah dijelaskan di atas.

Saya melihat sebagian besar masalah dengan buruh pelabuhan yang tidak dapat memulai kembali tanpa mematikan sub
kontainer. yang membuat konfigurasi/konfigurasi ulang jauh lebih sulit.

Pada Wed, Apr 15, 2015 at 08:11, Jan Krueger [email protected]
menulis:

+1

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/8887#issuecomment -93362359.

Saya cukup kecewa karena belum ada tindakan yang diambil untuk masalah ini. Ini jelas menyebabkan sejumlah orang kesakitan.

Ini jelas mengganggu banyak orang, itu secara aktif menghalangi pekerjaan saya sekarang. Harus me-restart daemon Docker untuk memungkinkan penarikan dari registri yang tidak aman berkisar dari yang mengganggu hingga benar-benar tidak mungkin tergantung pada situasi yang Anda hadapi.

Argumen utama untuk tidak melakukan ini tampaknya adalah bahwa administrator sistem harus dapat mengunci sistem dan memastikan bahwa hanya gambar dari repositori aman yang dapat ditarik. Kasus penggunaan itu benar-benar nyata tetapi saya pikir itu membuat default yang buruk. Tampaknya jauh lebih masuk akal untuk memiliki flag yang dapat diteruskan ke daemon saat awal seperti --no-insecure yang menonaktifkan penggunaan --insecure-registry di pull . Dengan begitu seorang admin dapat mengunci semuanya jika dia benar-benar menginginkannya.

Bagi mereka yang sangat menginginkan perilaku ini, saya menawarkan solusi berikut. Saya mengerti itu tidak akan layak untuk semua pengguna karena tidak menggunakan Docker API untuk menarik. Ini juga agak lambat ...

Lihat proyek saya 'docker-pull': https://github.com/ewindisch/docker-pull

Anda akan menggunakannya seperti itu:

docker run ewindisch/docker-pull --insecure-registry 10.0.0.0/16 10.0.1.2/someimage | docker load

Anda juga dapat mengizinkan semua pendaftar sebagai tidak aman:

docker run ewindisch/docker-pull --insecure 10.0.1.2/someimage | docker load

Saya akan mengingatkan bahwa _still_ sangat tidak disarankan untuk benar-benar melakukan ini.

@ewindisch hack yang bagus.

Solusi lain yang cukup bagus adalah dengan menggunakan tcp tunnel:

$ docker pull host:5000/image #fails
$ ssh -N -L 5000:host:5000 user<strong i="8">@host</strong>
$ docker pull localhost:5000/image #works

Ini adalah kedua solusi yang fantastis!

Saya juga ingin melihat default dibalik.

Pada 15 April 2015, pukul 18:14, Joe Doliner [email protected] menulis:

Saya cukup kecewa karena belum ada tindakan yang diambil untuk masalah ini. Ini jelas menyebabkan sejumlah orang kesakitan.

Ini jelas mengganggu banyak orang, itu secara aktif menghalangi pekerjaan saya sekarang. Harus me-restart daemon Docker untuk memungkinkan penarikan dari registri yang tidak aman berkisar dari yang mengganggu hingga benar-benar tidak mungkin tergantung pada situasi yang Anda hadapi.

Argumen utama untuk tidak melakukan ini tampaknya adalah bahwa administrator sistem harus dapat mengunci sistem dan memastikan bahwa hanya gambar dari repositori aman yang dapat ditarik. Kasus penggunaan itu benar-benar nyata tetapi saya pikir itu membuat default yang buruk. Tampaknya jauh lebih masuk akal untuk memiliki flag yang dapat diteruskan ke daemon di awal seperti --no-insecure yang menonaktifkan penggunaan --insecure-registry di tarik. Dengan begitu seorang admin dapat mengunci semuanya jika dia benar-benar menginginkannya.

—
Balas email ini secara langsung atau lihat di GitHub.

jadi ini dibuka kembali dan status saat ini setelah 4 bulan tidak ada apa-apa dan sebagai solusinya gunakan banyak peretasan? :-/ Apakah ada diskusi tentang ini terjadi di tempat lain atau hanya mati?

Dan ya, +1

+1

+1

Saya ingin menunjukkan bahwa saya menghitung contoh "+1" di halaman ini, dan jumlahnya mencapai 31 sejauh ini. Itu belum termasuk komentar pendukung lainnya yang tidak benar-benar menyertakan string yang tepat itu.

Masalahnya di sini adalah bahwa mengaktifkan --insecure pada tarikan mengambil kendali dari sysadmin, tempatnya berada.
Keamanan itu sulit, dan membuat perubahan untuk melonggarkan keamanan bukanlah keputusan kecil.
Juga, orang yang sangat senang dengan pengaturan saat ini tidak akan datang ke sini dan -1 ini juga.
Di samping itu...
Sangat mudah untuk mengkonfigurasi ulang daemon untuk mengaktifkan penarikan yang tidak aman dari registri.
Ini juga sepele untuk mengatur beberapa sertifikat yang ditandatangani sendiri dan bahkan tidak perlu mengkonfigurasi ulang buruh pelabuhan.

"Sysadmin" adalah salah satu kasus penggunaan untuk buruh pelabuhan, tetapi saya "pengembang" dan "non-sysadmin" adalah kasus penggunaan yang sama-sama valid. Untuk pengembang, memberikan opsi --insecure mengurangi gesekan dalam alur kerja.

Mungkin kita bisa mendapatkan yang terbaik dari kedua dunia dengan menyediakan opsi yang dapat ditentukan oleh sysadmin untuk _menolak_ penggunaan opsi --insecure . Dengan begitu, sysadmin masih memiliki kontrol penuh, tetapi kasus non-sysadmin tidak harus berurusan dengan kesulitan alur kerja.

Apa yang sepele bagi seorang sysadmin bisa sangat merepotkan bagi non-sysadmin. Saya harus membantu hampir dua lusin pengembang membuat (dan membuat ulang) perubahan konfigurasi ini di 5 OS berbeda yang digunakan dalam grup pengembangan kami. Saya benar-benar memelihara skrip untuk mengotomatiskan perubahan konfigurasi untuk lingkungan kami.

Sysadmin kami saat ini tidak akan mengatur sertifikat yang ditandatangani sendiri untuk registri kami, apakah itu sepele untuk dilakukan atau tidak.

Bagaimanapun, bahkan jika ini tidak berubah, pada akhirnya orang akan beradaptasi dengan mereka. Saya kira rasa sakit yang saya hadapi semua akan hilang saat sysadmin kami melakukan pemeliharaan pada registri, karena pada saat itu kami harus bisa menginstal sertifikat SSL yang sebenarnya. Mungkin itulah intinya. Jadikan lebih mudah untuk mengambil jalur aman daripada jalur tidak aman ke depan.

:+1: @CleanCut , dan semua orang mengatakan semuanya. Saya hanya bekerja dengan kasus pengembang dan mengkonfigurasi ulang daemon buruh pelabuhan hanya membuang-buang waktu bagi kami.

Jika Anda memiliki akses ke soket buruh pelabuhan hari ini, Anda _adalah_ seorang sysadmin. kamu adalah
root sudah, Anda memiliki "beban buruh pelabuhan" dan sudah memiliki solusi untuk dilakukan
tarik registri tidak aman. Menambahkan opsi gambar ke klien tidak akan
kurang aman dari status quo.

Namun, ada sesuatu yang bisa dikatakan tentang sengaja meningkatkan
gesekan bagi pengembang yang mencoba melakukan hal yang salah di lain untuk menarik
mereka untuk melakukan yang benar.
Pada 18 Jun 2015 12:41, "Brian Goff" [email protected] menulis:

Masalahnya di sini adalah mengaktifkan --insecure on pull menghilangkan kendali
dari sysadmin, tempatnya.
Keamanan itu sulit, dan membuat perubahan untuk melonggarkan keamanan bukanlah hal kecil
keputusan.
Juga, orang-orang yang sangat senang dengan pengaturan saat ini tidak akan pergi
untuk datang ke sini dan -1 ini juga.
Di samping itu...
Sangat sepele untuk mengonfigurasi ulang daemon untuk mengaktifkan penarikan yang tidak aman dari a
pendaftaran.
Ini juga sepele untuk menyiapkan beberapa sertifikat yang ditandatangani sendiri dan bahkan tidak perlu
konfigurasi ulang buruh pelabuhan.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/8887#issuecomment -113213172.

@ewindisch @tiborvass membaca kembali, saya melihat https://github.com/docker/docker/issues/8887#issuecomment -75638745;

Menyadari ini adalah masalah yang berkelanjutan bagi sejumlah besar pengguna, kami mempertimbangkan kembali untuk menambahkan --insecure untuk ditarik. @ewindisch dan saya akan mengerjakan PR yang akan kami tautkan ke masalah ini.
Maaf untuk menunggu lama, dan terima kasih telah menyuarakan pendapat Anda dan menunjukkan poin rasa sakit Anda.

Apakah itu masih posisi saat ini? (Saya tidak berpikir PR dibuat)

+1

Ini terus mengganggu dan mengganggu saya setiap hari.

:( sedih kepala kerucut.

--inscure masuk akal sepenuhnya dari POV pengembang. Ini pada orang yang mengimplementasikan buruh pelabuhan di lingkungan mereka untuk membuatnya aman.

+1

:+1:

_POLONGAN PENGGUNA_

_Cara terbaik untuk mendapatkan notifikasi jika ada perubahan dalam diskusi ini adalah dengan mengklik tombol Subscribe di kanan atas._

Orang-orang yang tercantum di bawah ini menghargai diskusi bermakna Anda dengan +1 acak:

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@mingfang
@djannot
@Frusty
@tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ryan-stateless
@jonathanvaughn
@gollawil
@ebartz
@maelp

+1

+1

+1

Kami menggunakan registri internal dalam jaringan tertutup, menambahkan ini akan membuat penyebaran lebih mudah bagi kami.

+1

Jika masalah ini masih terbuka pada Halloween, saya pikir semua +1 harus mengadakan pesta ulang tahun tenggelam-dalam-dokter-kami-kami.

+1 untuk pesta kesedihan!

Pada Sep 14, 2015, at 01:32, Gordon [email protected] menulis:

POLISI PENGGUNA

Cara terbaik untuk mendapatkan notifikasi jika ada perubahan dalam diskusi ini adalah dengan mengklik tombol Subscribe di kanan atas.

Orang-orang yang tercantum di bawah ini menghargai diskusi bermakna Anda dengan +1 acak:

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@mingfang
@djannot
@Frusty
@tobegit3hub
@testaccountspivey
@mhamrah
@mwhooker
@ryan-stateless
@jonathanvaughn
@gollawil
@ebartz
@maelp

—
Balas email ini secara langsung atau lihat di GitHub.

+1

+1 untuk pesta kesedihan

Pemilik bot yang memberi tahu orang-orang untuk berhenti menggunakan "+1":
kami menggunakan +1 untuk mengatasinya dan tidak banyak lagi yang bisa dikatakan.

+1

+1

Ada beberapa solusi, termasuk menggunakan terowongan SSH -- tetapi itu memerlukan akun ssh di host registri. Solusi berikut, tidak membutuhkan itu.

Jalankan penerus port registri, sebagai berikut:

docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder

Dan kemudian tarik atau dorong gambar dari registri lokal Anda:

docker pull localhost:5000/your-image
docker push localhost:5000/my-image

@rsmoorthy Itu fantastis. Terima kasih telah secara ringkas menunjukkan kesia-siaan pembatasan saat ini.

Docker, harap sertakan kembali baterai khusus ini.

+1

Saya harus mengatakan bahwa mendorong keamanan secara paksa pada pengguna telah secara serius mempengaruhi pemikiran saya tentang penggunaan buruh pelabuhan. Saya mengerti sepenuhnya bahwa kita dapat menambahkan flag --insecure-registry ke daemon saat memulai, dan saya tidak akan membahas semua alasan yang tidak selalu berfungsi, atau tidak mungkin.

Saya punya pertanyaan untuk pengembang Docker, apakah Anda benar-benar berpikir bahwa Anda tahu apa yang terbaik untuk pengguna akhir? I untuk satu tidak memerlukan SSL pada pendaftar saya sama sekali, karena jaringan yang mereka jalankan sudah dienkripsi sepenuhnya. Jadi mengapa saya mengenkripsi lalu lintas terenkripsi, apakah ini benar-benar melakukan apa pun selain menambahkan overhead dan memindahkan bagian ke sistem yang sudah kompleks dan masif?

Juga apakah benar-benar ada kasus penggunaan di mana orang menggunakan registri pribadi melalui internet? Apa yang dilakukan seseorang tentang otentikasi dalam pengertian itu? Tidak bisakah seseorang menarik gambar ke bawah dan kemudian merobeknya? Alih-alih mencoba mencegatnya dalam perjalanan ke komputer lain?

TL;DR+1

+1

@Supernomad berkata dengan baik.

Lihat dari sisi buruh pelabuhan: ini adalah salah satu masalah yang lebih baik disimpan tidak pernah diimplementasikan secara resmi, tetapi dengan banyak kemungkinan solusi untuk mengurangi rasa sakit. Beberapa pengguna yang berteriak keras masih kurang menyakitkan daripada pemasaran pesaing yang melabeli buruh pelabuhan sebagai "sengaja tidak aman", dan merusak reputasinya selamanya.
Karena itu, +1.

@tiborvass @ewindisch Masalah ini sudah lebih dari satu tahun. Sudah lebih dari 8 bulan sejak Anda mengatakan itu akan dievaluasi ulang. Sudahkah Anda mengevaluasinya? Jika demikian, apa yang telah diputuskan? Jangan biarkan seorang saudara digantung! :-)

Sejak masalah ini awalnya dibuka dan ditutup dan dibuka kembali, komunitas telah menemukan banyak cara untuk memperbaikinya sendiri, terutama untuk menunjukkan kesia-siaan pengaturan default ini:

• ssh -N -L 5000:host:5000 user<strong i="10">@host</strong> && docker pull localhost:5000/lolsecurity
• socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 && docker pull localhost:5000/lolsecurity
• docker-machine create -d virtualbox --engine-insecure-registry 0.0.0.0/0 lolsecurity
• docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder && docker pull localhost:5000/lolsecurity

Belum lagi CoreOS sekarang dikirimkan dengan --insecure-registry 0.0.0.0/0 sebagai default. Contoh-contoh ini dengan jelas menunjukkan bahwa gagasan bahwa ada garis pemisahan kekhawatiran antara "sysadmin" dan "pengembang" sekarang sebagian besar sewenang-wenang dan palsu pada tahun 2015. Faktanya, gagasan wadah (di mana Docker adalah kepala mereka evangelist) telah mempercepat tren ini jauh dari operasi tradisional yang masih mengganggu untuk memanggil siapa pun "sysadmin" di tempat pertama.

Bagaimanapun, saya ingin melihat ini ditutup untuk selamanya, dengan satu atau lain cara.

+1

+1

+1

Mengapa saya harus mempercayai Docker Registry dengan kunci pribadi SSL saya?

Untuk pengguna CoreOS lain yang dibiarkan kering dengan campur tangan ini,
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registry-without-ssl-configured

@politician sendiri tidak bisa mengatakannya dengan lebih baik. Yang paling pasti, sepertinya buruh pelabuhan mengabaikan fakta bahwa sebagian besar pengguna mereka setidaknya tidak puas.

Faktanya adalah saya sedang dalam proses migrasi sepenuhnya dari buruh pelabuhan dan saya tidak bisa lebih bahagia dengan keputusan itu. Saat ini saya menggunakan git dan lxc dan tidak hanya turun lebih cepat daripada buruh pelabuhan, itu benar-benar memungkinkan saya untuk melakukan yang terbaik untuk perusahaan saya dan bukan apa yang dipikirkan perusahaan lain, meskipun sepenuhnya dan sepenuhnya salah, yang terbaik untuk saya.

Saya sangat menyarankan untuk melihat alternatif yang sejujurnya lebih baik daripada buruh pelabuhan, seperti roket, raw lxc, qemu (tidak sama tetapi masih lebih baik) hanya untuk beberapa nama.

Saya akan sangat menyarankan tindakan ini kepada semua orang yang saya kenal yang sedang mempertimbangkan kontainer mulai sekarang. Setidaknya sampai orang-orang di buruh pelabuhan menyadari bahwa mereka tidak tahu, dan saya tekankan _absolutely_ tidak tahu, apa yang terbaik untuk pengguna akhir dalam hal keamanan.

Saya menyerah dan membeli sertifikat SSL khusus yang murah. Ketergantungan Docker CLI pada sistem CA terlalu kuat - sertifikat yang ditandatangani sendiri tidak hanya membuat frustrasi operasional, tetapi juga tidak berfungsi.

• docker-machine menghapus penggantian ca.crt Anda antara bawah/atas
• tidak ada gambar dasar Anda yang menyertakan alat pembuat sertifikat seperti drone untuk CI tidak mungkin
• docker CLI menggunakan folder non-standar untuk sertifikat, jadi itu hanya hal lain yang perlu diingat.
• bahkan jika Anda membuatnya bekerja 18 jam kemudian, Anda akan selalu memiliki perasaan yang mengganggu bahwa ada sesuatu yang rusak

Intinya: Docker memberikan penalti berkelanjutan yang terus-menerus kepada tim operasi Anda ketika mencoba menggunakan sertifikat yang ditandatangani sendiri.

Ini semakin membuat frustrasi karena curl -k telah ada untuk selamanya.

+1

Sangat menyedihkan, bahwa mereka tidak peduli tentang ini. Jika beberapa dev hanya ingin bermain-main dengan buruh pelabuhan dan meng-host lingkungannya sendiri, biasanya Anda tidak ingin dipusingkan dengan sertifikat SSL dan lainnya. Selain itu, jika Anda memiliki server sendiri di rumah yang tidak dapat diakses oleh publik, Anda tidak memerlukan SSL.

@buehler Anda dapat menambahkan opsi --insecure-registry ke pengaturan daemon Anda, atau ke file konfigurasi daemon.json Anda; maka Anda hanya perlu mengonfigurasinya sekali, dan menarik tanpa harus menentukan bendera

Hanya pembaruan dari kami: Sejak itu kami menghapus Registry dari infrastruktur kami dan kembali menggunakan

@buehler hanya untuk mengkonkretkan proposal @thaJeztah , tambahkan baris ini ke konfigurasi:

--insecure-registry 0.0.0.0/0

Anda akan dapat mengakses registri apa pun yang Anda inginkan. Berfungsi dengan baik untuk menguji barang.

@politician duplikasi terjadi jika gambar ditandai dengan repositori yang berbeda. Kurangnya penghapusan gumpalan adalah masalah yang jauh lebih besar.

@thaJeztah jika itu mudah dilakukan, tetapi 80% (jumlah yang

@justinclayton tidak; pengaturan opsi itu pada dasarnya mengatakan "abaikan masalah apa pun dengan komunikasi aman ke registri", jadi izinkan serangan man-in-the-middle "di luar kotak", atau bahkan daemon yang jatuh kembali ke non-TLS "http://" . Docker _does_ sudah menetapkannya sebagai default untuk registri di kisaran 127.x.x.x .

Jika Anda memiliki registri lokal dan tidak ingin membuat sertifikat untuknya, menambahkan --insecure-registry ke opsi daemon Anda membutuhkan waktu kurang dari satu menit. Itu harus menjadi tindakan yang disengaja, bukan sesuatu yang diatur secara default.

@thaJeztah Saya mengerti argumen Anda, tetapi itu tidak bisa hanya menjadi akhir dari itu. Ada kesenjangan yang signifikan dalam pengalaman pengguna untuk pengembang baru karena ini berada di sisi daemon. Skenario _mayority_ di mana ini menyebalkan adalah pengembang baru yang mengikuti instruksi di docker.com untuk mengunduh dan menjalankan penginstal Docker Toolbox di Mac mereka. Setelah selesai, mereka segera mencoba menjalankan docker pull <internally-signed-registry>/foo dan disambut dengan kesalahan. Ini adalah masalah yang sebenarnya. Mungkin itu berarti masalah ini harus diganti namanya?

Ada banyak cara lain yang juga bisa diselesaikan; Saya yakin komunitas dan perusahaan bisa menyepakati salah satunya:

• Nama saat ini dari masalah ini adalah '--registry-insecure-harus ada di "docker pull"'. Karena masalah ini masih terbuka, saya harus menganggap opsi ini masih dipertimbangkan.
• Jika solusi satu perintah untuk ini disediakan (dan didokumentasikan) yang sederhana untuk pengguna pemula, itu akan menyelesaikan ini.
• Dalam kasus kami, registri _is_ diamankan. Ini menggunakan sertifikat yang ditandatangani oleh CA internal kami seperti yang lainnya di lingkungan build kami. Ini adalah keamanan yang cukup. Jika daemon entah bagaimana mampu menghormati penyimpanan sertifikat MacOS, itu akan membuat sakit kepala ini hilang juga.
• Jika mereka diminta untuk menambahkan sertifikat atau membuat konfigurasi ini ke mesin buruh pelabuhan selama proses pemasangan Toolbox, itu mungkin juga akan baik-baik saja.

Harap beri tahu 70+ peserta masalah ini tentang arah yang Anda rencanakan untuk diambil dengan ini, atau tolong tutup saja masalah ini sehingga kami tidak dibiarkan menggantung. Terima kasih.

@thaJeztah
Tidak ada cara untuk menambahkan --insecure-registry tunggal ke daemon opts tanpa memulai ulang semua container yang sedang berjalan. Itu adalah salah satu masalah utama. Kami tidak dapat memuat ulang konfigurasi tanpa memulai ulang (masalah berlangsung sejak 2013), kami tidak dapat menarik gambar dari registri tidak aman lainnya tanpa menambahkan opsi ke daemon dan juga memulai ulang. Dan saat ini kami masih belum memiliki peta jalan yang jelas untuk memperbaiki masalah itu.

@apakhomov kira itu bisa ditambahkan ke daftar perubahan konfigurasi yang dapat diperbarui tanpa memulai ulang https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading. Bisakah Anda membuka masalah terpisah untuk itu?

+1.

Beberapa penyedia PaaS tidak memberikan akses ke daemon dan menjalankan jaringan pribadi untuk pengguna (Jelastic misalnya).

apakah mungkin menambahkan beberapa pendaftar tidak aman ke buruh pelabuhan?
sesuatu seperti --insecure-registry xxxx:xxxx --insecure-registry zzzz:zzzz

@kkorada --insecure-registry=0.0.0.0/0 akan membuat Docker berperilaku seperti sebelumnya.

@kkorada ya, Anda dapat menentukan beberapa pendaftar (benderanya adalah --insecure-registry=[] - tanda kurung siku menunjukkan itu dapat ditentukan beberapa kali).

Juga untuk docker 1.12, kami akan membuat opsi ini dapat dikonfigurasi dalam file konfigurasi daemon.json , tanpa me-restart daemon. Lihat permintaan tarik terbuka di sini: https://github.com/docker/docker/pull/22337

terima kasih @mingfang dan @thaJeztah

Sebagai @mhamrah dan @justinclayton menyarankan , saya juga akan merekomendasikan solusi menggunakan ssh selain TLS, mirip dengan bagaimana Git memungkinkan akses ke respository menggunakan kedua ssh dan TLS. Ini mungkin menggunakan solusi ssh yang terdaftar @justinclayton .

Meskipun saya tidak memiliki data untuk mendukung klaim saya, saya kira ada lebih banyak pendaftar pribadi yang berjalan di belakang firewall daripada pendaftar yang berjalan di Internet terbuka. Dalam hal ini, ssh lebih mudah dikonfigurasi dan, jika tidak lebih, lebih aman daripada TLS.

Selanjutnya, setelah berjuang selama berhari-hari dengan docker push dan registri pribadi lokal saya berjalan di dalam mesin virtual internal yang cukup aman (dan lebih banyak waktu berjuang untuk membuat sertifikat yang ditandatangani sendiri), saya baru saja benar-benar menghargai rkt --insecure-options=image,tls,http .

Ini gila karena ini bukan pengaturan klien. Jelas itu tidak boleh diaktifkan secara default karena itu akan mendorong praktik yang tidak aman. Menempatkan pengaturan pada daemon membuatnya sangat tidak praktis untuk tujuan debugging atau di lingkungan pengembangan lokal.

Kasus penggunaan saya saat ini: menjalankan lingkungan pengembangan dengan docker compose. Lingkungan membutuhkan registri buruh pelabuhan lokal. Ini dimaksudkan untuk berjalan sepenuhnya pada VM lokal.

Cara buruh pelabuhan: menjelaskan cara mengonfigurasi mesin buruh pelabuhan untuk mengaktifkan registri tidak aman pada setiap mesin pengembang, mungkin mengharuskan mereka untuk membuat ulang mesin buruh pelabuhan jika mereka sudah memilikinya atau mengedit konfigurasi secara manual.

Solusi peretasan: socat berjalan di setiap wadah yang perlu menggunakan registri, mengalihkan ke localhost.

Tidak benar-benar membuat segalanya mudah ...

+1

Sangat disayangkan --insecure tidak menjadi konfigurasi klien!
Itu menciptakan banyak rasa sakit bagi kita juga sangat mirip dengan banyak penjelasan di atas.
Harap atur --insecure-registry=0.0.0.0/0 secara default sebelum memberikan cara untuk meneruskannya ke perintah docker serta konfigurasi komposisi docker.

+1

+1

Apakah sudah waktunya untuk Pesta Kasihan +1 tahunan lagi?

Pada 13 Desember 2016, pukul 1:00 pagi, [email protected] menulis:

+1

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

Jika lapisan gambar ditandatangani, tidak perlu menggunakan CA PKI untuk keamanan. Lihat juga cara kerja apt/yum. Selain itu, menggunakan SSL di LAN tidak masuk akal, dan di lingkungan cloud itu berarti Anda harus menyediakan - selain dari sertifikat itu sendiri - untuk sumber keacakan yang baik (lihat juga: https://lukehinds.github.io/2015-03 -03-Entropi-dalam-awan/).

Singkat cerita: jika tidak perlu, jangan paksakan pada pengguna.

Saya baru saja membuka #29736 yang terkait.

+1, jika memiliki bendera sisi klien --insecure-registry bukan merupakan opsi, harus ada cara untuk menentukan sertifikat tepercaya yang akan digunakan untuk docker pull dan docker push . Tidak semua orang memiliki akses ke sertifikat kepercayaan pada tingkat OS, atau akses untuk bermain-main dengan daemon Docker.

Server CI yang dihosting (yang digunakan untuk membuat image buruh pelabuhan dan mendorong ke registri pribadi) adalah contoh yang bagus ketika Anda mungkin tidak memiliki tingkat akses tersebut.

+1

@ajhodges https://docs.docker.com/registry/insecure/#using -self -signed-certificates

@tiborvass
Hanya berfungsi jika Anda memiliki akses Sudo ...

+1 cara yang baik untuk mencegah pengembang menggunakan buruh pelabuhan

+1, saya ingin melihat --insecure-registry untuk docker login juga.

Saya bahkan tidak melihat ini sebagai masalah keamanan, karena Anda secara sadar melakukannya. Dan jika seseorang yang tidak berwenang mendapat akses root, ini juga tidak akan memberikan keamanan apa pun. Manfaat apa yang sebenarnya dimiliki pembatasan ini?

Jika Anda memiliki niat buruk, Anda bisa mengunggah gambar buruh pelabuhan jahat Anda ke DockerHub, yang tepercaya.

+1 dan terus terang ini mengejutkan pikiran

+1 ke kereta rasa sakit.

Ditambah F * cking Satu!

Apakah ada PR terbuka untuk ini?

Bukan AFAIK. Tautan di atas dibuat karena beberapa kode saya sendiri merujuk pada masalah ini. Saya akan menarik referensi itu sebentar untuk menenangkan spam di sini.

+1 juga...

+1

+1 , sangat merepotkan untuk menambahkan pengaturan ke deamon.json dan memulai ulang buruh pelabuhan.

Mesin yang berbeda memiliki os yang berbeda. Beberapa menginstal buruh pelabuhan dari yum apt-get , dan beberapa langsung menggunakan binary . Jadi saya harus mendeteksi itu dan me-restart dockerd dengan benar .... itu bencana

Saya hanya menekankan docker pull perlu --insecure-registry flag !

Baru tiga tahun - jangan kehilangan harapan sekarang

benjolan

+1

+1

Argumen bahwa hal ini mendorong pengguna untuk menetapkan registri mereka sebagai aman tidak hanya sombong, tetapi juga kehilangan poin kunci. Ini menempatkan operasi pada posisi di mana banyak orang harus memiliki akses ke akun root untuk melakukan pekerjaan operasi mereka, di mana pendaftar buruh pelabuhan sering berpindah-pindah.
Kopling itu, dari sudut pandang keamanan operasional, menciptakan risiko keamanan yang lebih besar.

Kedua, dalam jaringan pribadi (seperti dalam aplikasi multi-tier cloud-hosted), pengamanan registri tidak diperlukan, dan semakin memperumit implementasi teknologi yang berada di atas, memerlukan lapisan manajemen keamanan (untuk menangani otentikasi buruh pelabuhan otomatis/ refresh) di mana pun registri buruh pelabuhan yang aman digunakan.

Paling tidak, daemon buruh pelabuhan harus dapat dikonfigurasi untuk MENGIZINKAN parameter registri tidak aman untuk dilewatkan. Itu memindahkan desain keamanan ke tempat yang tepat - di tangan administrator, dan di luar buruh pelabuhan itu sendiri.

FWIW Saya akan senang dengan perintah untuk "menambahkan beberapa registri ke daftar pendaftar yang tidak aman", karena menambal konfigurasi json dari skrip shell adalah titik sakit utama.

+1

:+1: +1

+1

+1

+1

+1

Banyak dari implementasi yang diminta ini akan membuat perusahaan yang menggunakan Docker tidak mungkin untuk mematuhi persyaratan kepatuhan SOC, dll.

Seharusnya ada solusi untuk ini, tetapi saya tidak berpikir ada solusi mudah yang tidak akan menjadi perubahan arsitektur yang lebih drastis pada bagaimana gambar disimpan dan dieksekusi.

Tetap saja, itu harus terjadi.

Saya tidak lagi terlibat dengan pengembangan Docker jadi saya akan menghapus diri saya dari sebutan. Selamat mencoba ya ^_^

Persyaratan SOC adalah poin yang bagus. Dalam hal ini, fitur ini harus DIAKTIFKAN dengan opsi konfigurasi untuk ditambahkan ke konfigurasi buruh pelabuhan seluruh sistem. Dengan begitu persyaratan SOC dapat dipertahankan. Sesuatu seperti "ALLOW_INSECURE_REGISTY_OPTION" yang mengaktifkan flag --insecure-registry pada baris perintah buruh pelabuhan.

Untuk kepatuhan SOC, opsi tidak boleh diaktifkan.

+1

Baru tiga tahun - jangan kehilangan harapan sekarang

5.

Proposal ini (dalam bentuknya yang sekarang) sangat kecil kemungkinannya untuk dilaksanakan, karena berbagai
alasan, di antaranya;

• itu membuat orang yang mengelola daemon buruh pelabuhan bertanggung jawab atas koneksi apa
  daemon diizinkan untuk dibuat. perhatikan bahwa opsi ini dapat "dimuat ulang secara langsung",
  jadi daemon tidak harus direstart untuk mengubah konfigurasi.
• setiap perintah atau jalur kode yang berpotensi berinteraksi dengan registri akan memiliki
  untuk dimodifikasi; tidak hanya docker pull , tetapi juga docker build , docker run ,
  docker plugin , docker service dan docker stack , serta
  orkestra seperti swarmkit, yang menarik gambar dari node pekerja.
• Kepatuhan SOC (seperti yang disebutkan di atas)

Paling tidak, daemon buruh pelabuhan harus dapat dikonfigurasi untuk MENGIZINKAN tidak aman
parameter registri yang akan diteruskan. Itu memindahkan desain keamanan ke yang benar
tempat - di tangan administrator, dan di luar buruh pelabuhan itu sendiri.

Saya pikir administrator dalam hal ini adalah orang/tim yang mengelola
host tempat daemon buruh pelabuhan berjalan, bukan pengguna yang terhubung ke remote
API. Inilah alasan mengapa konfigurasi ini menjadi konfigurasi daemon.

menambal konfigurasi json dari skrip shell adalah masalah utama.

Itu poin yang adil, tetapi ortogonal untuk diskusi ini. Bukan _tidak mungkin_
untuk menambal konfigurasi JSON, tetapi setuju bahwa itu bisa lebih rumit daripada yang lain
format file. Perhatikan bahwa konfigurasi ini juga dapat diatur sebagai melalui flag on
daemon, yang memungkinkan Anda menggunakan file unit drop-in systemd untuk mengkonfigurasi ulang
daemon.

Sesuatu seperti "ALLOW_INSECURE_REGISTY_OPTION" yang mengaktifkan flag --insecure-registry pada baris perintah buruh pelabuhan.

Jika Anda ingin mengizinkan penarikan yang tidak aman dari registri apa pun (yang akan setara
menambahkan flag --insecure-registry ), Anda dapat mengizinkan "internet" sebagai tidak aman
pendaftaran; berikut ini harus mengizinkan alamat IPv4 apa pun untuk digunakan sebagai registri tidak aman,
(sehingga kembali ke koneksi non-TLS);

Melalui file konfigurasi /etc/docker/daemon.json ;

{"insecure-registries": ["0.0.0.0/1","128.0.0.0/2","192.0.0.0/3","224.0.0.0/4"]}

Atau dengan meneruskan opsi sebagai flag pada daemon (yang dapat diatur dalam systemd
menimpa file);

dockerd \
    --insecure-registry=0.0.0.0/1 \
    --insecure-registry=128.0.0.0/2 \
    --insecure-registry=192.0.0.0/3 \
    --insecure-registry=224.0.0.0/4