Saya ingin tahu apakah #6075 akan memberikan apa yang Anda butuhkan

Wadah rahasia mungkin membuatnya sedikit lebih aman, tetapi semua poin yang disebutkan masih berlaku.

+1 Saya akan menemukan kemampuan ini berguna juga. Khususnya ketika membangun wadah yang memerlukan perangkat lunak dari repo git pribadi, misalnya. Saya lebih suka tidak harus membagikan kunci repo ke dalam wadah, dan sebaliknya ingin dapat memiliki "docker build ..." menggunakan beberapa metode lain untuk mendapatkan akses ke kunci SSH yang tidak terkunci, mungkin melalui ssh yang sedang berjalan -agen.

+1. Saya baru saja mulai membasahi kaki saya dengan Docker dan ini adalah penghalang pertama yang saya pukul. Saya menghabiskan beberapa saat mencoba menggunakan VOLUME untuk memasang kaus kaki auth sebelum saya menyadari bahwa buruh pelabuhan tidak dapat/tidak akan memasang volume Host selama pembuatan.

Saya tidak ingin salinan kunci SSH tanpa kata sandi tergeletak di sekitar dan mekanisme menyalinnya ke dalam wadah lalu menghapusnya selama pembuatan terasa salah. Saya bekerja di dalam EC2 dan bahkan tidak merasa nyaman menyalin kunci pribadi saya di sana (tanpa kata sandi atau tidak.)

Kasus penggunaan saya sedang membangun proyek erlang dengan rebar. Benar saja, saya _could_ mengkloning repo pertama dan menambahkannya ke gambar dengan Dockerfile, tetapi itu tidak berfungsi dengan dependensi pribadi yang dimiliki proyek. Saya kira saya bisa membangun proyek di mesin Host dan MENAMBAHKAN hasilnya ke gambar Docker baru, tetapi saya ingin membangunnya di kotak pasir yaitu Docker.

Berikut adalah beberapa orang lain yang memiliki kasus penggunaan yang sama: https://twitter.com/damncabbage/status/453347012184784896

Tolong, rangkul SSH_AUTH_SOCK, ini sangat berguna.

Terima kasih

Sunting: Sekarang saya tahu lebih banyak tentang cara kerja Docker (lapisan FS), tidak mungkin melakukan apa yang saya jelaskan sehubungan dengan MENAMBAH kunci SSH selama membangun dan menghapusnya nanti. Kuncinya akan tetap ada di beberapa lapisan FS.

+1, dapat menggunakan SSH_AUTH_SOCK akan sangat berguna!

Saya menggunakan kunci SSH untuk mengautentikasi dengan Github, baik itu repositori pribadi atau publik.

Ini berarti perintah git clone terlihat seperti: git clone [email protected]:razic/my-repo.git .

Saya dapat me-mount direktori ~/.ssh Host saya ke dalam wadah saya selama docker run dan ssh semuanya baik-baik saja. Namun saya tidak dapat memasang ~/.ssh selama docker build .

:+1: untuk penerusan ssh selama pembuatan.

Seperti yang saya mengerti ini adalah cara yang salah. Cara yang benar adalah membuat gambar buruh pelabuhan di mesin dev, dan kemudian menyalinnya ke server buruh pelabuhan.

@SevaUA - tidak, itu tidak benar. Permintaan ini karena batasan saat melakukan docker build... . Anda tidak dapat mengekspor variabel ke tahap ini seperti yang Anda lakukan saat melakukan docker run ... . Perintah run memungkinkan variabel untuk diekspor ke wadah buruh pelabuhan saat berjalan, sedangkan build tidak mengizinkannya. Batasan ini sebagian disengaja berdasarkan cara kerja buruh pelabuhan saat membangun wadah. Tetapi ada beberapa cara untuk mengatasi ini dan usecase yang dijelaskan adalah yang valid. Jadi permintaan ini mencoba untuk mengimplementasikan kemampuan ini dalam build, dengan cara tertentu.

Saya menyukai ide #6697 (toko rahasia/vault), dan itu mungkin berhasil untuk ini setelah digabungkan. Tetapi jika itu tidak berhasil, alternatifnya adalah melakukan hal-hal ssh proxy transparan man-in-the-middle di luar daemon buruh pelabuhan, mencegat lalu lintas daemon buruh pelabuhan (bukan secara internal). Atau, semua permintaan git+ssh bisa ke beberapa host yang ditentukan secara lokal yang secara transparan diproksi ke github atau apa pun yang akhirnya Anda butuhkan.

Gagasan itu telah diajukan (lihat komentar 2). Itu tidak menyelesaikan masalah.

+1 untuk penerusan ssh selama pembuatan.

+1 pada penerusan agen SSH pada docker build

+1 untuk penerusan ssh selama pembuatan untuk orang-orang seperti npm install atau serupa.

Adakah yang punya penerusan ssh yang berfungsi saat dijalankan di OSX? Saya telah mengajukan pertanyaan di sini: http://stackoverflow.com/questions/27036936/using-ssh-agent-with-docker/27044586?noredirect=1#comment42633776_27044586 sepertinya tidak mungkin dengan OSX...

+1 =(

Tekan saja penghalang jalan ini juga. Mencoba menjalankan npm install menunjuk ke repo pribadi. pengaturan terlihat seperti:
host -> vagrant -> docker dapatkah ssh-agent meneruskan host -> vagrant -! docker

+1
Tekan saja ini ketika mencoba mencari cara agar agen ssh berfungsi selama 'pembuatan buruh pelabuhan'.

+1 sama seperti orang-orang sebelumnya. Tampaknya solusi terbaik untuk masalah ini ketika perlu mengakses satu atau lebih repositori git pribadi (misalnya bundle install dan npm install ) ketika membangun image Docker.

Saya dapat memasang volume direktori Host ~/.ssh saya ke dalam wadah saya selama menjalankan buruh pelabuhan dan ssh semuanya baik-baik saja.

@razic Bisakah Anda membagikan bagaimana Anda membuatnya bekerja? Karena ketika saya mencobanya sebelumnya memang mengeluh tentang "Pemilik atau izin yang buruk"

Kecuali Anda memastikan bahwa semua wadah berjalan dengan pengguna atau izin tertentu yang memungkinkan Anda melakukan itu?

+1 ke SSH_AUTH_SOCK

@tonivdv lihat perintah docker run di komentar awal tentang masalah ini. Itu mengikat me-mount jalur yang dirujuk oleh SSH_AUTH_SOCK ke /tmp/ssh_auth_sock di dalam wadah, lalu menetapkan SSH_AUTH_SOCK dalam wadah ke jalur itu.

@md5 Saya berasumsi @razic dan @tonivdv berbicara tentang pemasangan seperti ini: -v ~/.ssh:/root/.ssh:ro , tetapi ketika Anda melakukan ini, file .ssh tidak dimiliki oleh root dan oleh karena itu gagal dalam pemeriksaan keamanan.

@KyleJamesWalker yup itu yang saya pahami dari @razic dan yang merupakan salah satu upaya saya beberapa waktu lalu, jadi ketika saya membaca @razic dapat membuatnya bekerja, saya bertanya-tanya bagaimana caranya :)

@tonivdv Saya juga ingin tahu apakah itu mungkin, saya tidak dapat menemukan apa pun ketika saya terakhir mencoba.

+1 Saya tertarik untuk membangun lingkungan pengembang sekali pakai menggunakan Docker tetapi saya tidak bisa membuatnya berfungsi. Ini akan banyak membantu dalam hal itu.

Bagi siapa pun yang mencari solusi sementara, saya memiliki perbaikan yang saya gunakan yang memaksa hal-hal di:

https://github.com/atrauzzi/docker-laravel/blob/master/images/php-cli/entrypoint.sh

Ini sama sekali bukan solusi yang diinginkan karena memerlukan seluruh skrip entrypoint, tetapi berhasil.

@atrauzzi pendekatan yang menarik. Untuk dev env kami, kami membuat gambar dasar dan menyalin kunci ssh langsung di dalamnya. Ini memiliki keuntungan karena tidak perlu menyediakannya di setiap putaran. Dan setiap gambar yang diwarisi dari penyihir itu secara default memiliki kunci di dalamnya juga. Namun dengan cara kami, Anda tidak dapat membagikannya secara publik dengan jelas ;p

+1 ini akan sangat bagus

@tonivdv Wadah tempat skrip dibuat dan dihancurkan sering karena itu hanya host untuk alat CLI. Anda tentu saja bebas melakukan operasi hanya sekali. Tetapi jika seseorang mengubah pengaturannya dan menjalankan kembali perintah melalui wadah, itu harus menjadi salinan baru setiap saat.

@atrauzzi saya mengerti. Pendekatan Anda harus diadopsi oleh gambar buruh pelabuhan yang mungkin memerlukan kunci ssh pribadi. Misalnya, gambar komposer harus menyertakan skrip titik masuk Anda jika ada repo pribadi. Setidaknya sampai buruh pelabuhan datang dengan solusi asli.

:+1: untuk penerusan ssh melalui build

Harus-memiliki di sini juga!

@atrauzzi Saya menggunakan pendekatan lain saat ini yang sangat saya sukai. Itu membuat wadah volume data dengan barang-barang ssh di dalamnya. Saat Anda ingin menggunakan kunci ssh Anda ke wadah lain, saya cukup menggunakannya dengan perintah berikut:

docker run -ti --volumes-from ssh-data ...

Dengan cara ini Anda tidak perlu menempatkan titik masuk pada setiap gambar dan itu dapat bekerja dengan semua gambar.

Untuk membuat wadah itu, saya melakukan hal berikut:

docker run \
  --name ssh-data \
  -v /root/.ssh \
  -v ${USER_PRIVATE_KEY}:/root/.ssh/id_rsa \
  busybox \
  sh -c 'chown -R root:root ~/.ssh && chmod -R 400 ~/.ssh'

Semoga ini bisa membantu orang lain :)

Bersulang

@tonivdv - Saya mengambil pendekatan saya karena jika seseorang harus menambah atau memperbarui pengaturan SSH, mereka harus diimpor ulang. Wadah khusus yang saya gunakan adalah wadah yang dibuat untuk menjalankan satu perintah, jadi setiap kali dijalankan, dibutuhkan salinan untuk memastikannya mutakhir.

@atrauzzi Ya saya mengerti. Karena itu, terserah pengguna untuk mempertahankan wadah volume ssh dengan benar. Dia bahkan dapat menggunakan yang berbeda jika perlu. Dan secara opsional dapat dibuat dengan cepat dengan skrip. Tapi saya tidak berpikir ada satu-satunya solusi yang baik. Itu semua tergantung kebutuhan. Hanya ingin berbagi agar orang lain dapat memilih solusi apa yang sesuai dengan kebutuhan mereka. Berharap untuk segera menulis blog tentang ini, dan saya akan meneruskan solusi Anda juga! Bersulang

Saya tidak akan membuat persyaratan bahwa orang yang menjalankan wadah Anda memelihara wadah khusus data yang penuh dengan kunci ssh. Tampaknya terlibat.

@atrauzzi Memang benar bahwa wadah volume harus ada di sana, tetapi dengan cara Anda, pengguna harus membagikan kunci ssh-nya saat berjalan juga kan? Jadi selain membutuhkan wadah volume ssh, satu-satunya perbedaan di kedua solusi dari sudut pandang berjalan adalah:

docker run ... --volumes-from ssh-data ... php-cli ...

dan

docker run ... -v ~/.ssh:/path/.host-ssh ... php-cli ..

Baik? Atau saya melewatkan sesuatu yang lain :)

Tapi saya benar-benar mengerti mengapa Anda melakukannya dengan cara Anda. Namun, jika Anda ingin menggunakan misalnya gambar komposer dari orang lain, cara volumes-from akan bekerja di luar kotak. Setidaknya itu menghindari untuk membuat gambar Anda sendiri dengan "retas titik masuk".

Seperti yang saya katakan, keduanya adalah solusi dan keduanya memiliki pro dan kontra.

Bersulang

Akan sangat bagus untuk mendapatkan pembaruan dari tim Docker tentang status fitur ini. Secara khusus, otentikasi SSH dari docker build .

Ini sudah mendekati 1 tahun. Agak mengejutkan, mengingat kepraktisan kasus penggunaan kehidupan nyata untuk ini. Saat ini, kami secara dinamis menghasilkan gambar dengan menjalankan container. Kami tidak dapat memiliki Dockerfile di repositori aplikasi kami. Ini memecah aliran untuk hampir semua hal. Saya tidak dapat benar-benar menggunakan aplikasi saya dengan layanan Docker seperti Compose atau Swarm sampai ini diselesaikan.

Pembaruan akan sangat dihargai. Silahkan dan terima kasih.

/cc @phemmer

Bukannya kami tidak menginginkan fitur ini atau apa pun, saya benar-benar melihat kasus penggunaan untuk sesuatu seperti ini atau rahasia dalam pembuatannya, kami hanya membutuhkan proposal dari seseorang yang bersedia mengimplementasikan dan kemudian jika menyetujui implementasi proposal.
Juga saya berbicara atas nama saya sendiri tidak semua pengelola.

@jfrazelle

Aku tahu kalian tidak mengabaikan kami :)

Jadi statusnya adalah:

Itu adalah sesuatu yang akan kami pertimbangkan untuk diterapkan jika ada proposal yang diterima
dan bandwidth rekayasa.

Apakah ini terdengar akurat untuk Anda?

Juga, apakah saat ini ada proposal terbuka yang membahas masalah ini?

Pada hari Selasa, 7 April 2015, Jessie Frazelle [email protected] menulis:

Bukannya kami tidak menginginkan fitur ini atau apa pun, saya benar-benar melihat kegunaannya
kasus untuk sesuatu seperti ini atau rahasia dalam pembuatan kita hanya perlu
proposal dari seseorang yang bersedia untuk menerapkan dan kemudian jika disetujui,
pelaksanaan usulan.
Juga saya berbicara atas nama saya sendiri tidak semua pengelola.

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

Itu adalah sesuatu yang akan kami pertimbangkan untuk diterapkan jika ada proposal yang diterima
dan bandwidth rekayasa.

Ya

Dan saya tidak berpikir ada proposal terbuka untuk ini.

Pada Sel, Apr 7, 2015 at 14:36, Zachary Adam Kaplan <
[email protected]> menulis:

@jfrazelle

Aku tahu kalian tidak mengabaikan kami :)

Jadi statusnya adalah:

Itu adalah sesuatu yang akan kami pertimbangkan untuk diterapkan jika ada proposal yang diterima
dan bandwidth rekayasa.

Apakah ini terdengar akurat untuk Anda?

Juga, apakah saat ini ada proposal terbuka yang membahas masalah ini?

Pada hari Selasa, 7 April 2015, Jessie Frazelle [email protected]
menulis:

Bukannya kami tidak menginginkan fitur ini atau apa pun, saya benar-benar melihat kegunaannya
kasus untuk sesuatu seperti ini atau rahasia dalam pembuatan kita hanya perlu
proposal dari seseorang yang bersedia untuk menerapkan dan kemudian jika disetujui,
pelaksanaan usulan.
Juga saya berbicara atas nama saya sendiri tidak semua pengelola.

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

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

Saya tidak tahu apakah saya terlalu menyederhanakan banyak hal, tetapi inilah proposal saya:

SSHAGENT: meneruskan # default untuk diabaikan

Jika disetel, selama pembuatan, soket & variabel lingkungan terkait terhubung ke wadah, di mana mereka dapat digunakan. Potongan mekanis ini sudah ada dan berfungsi, hanya masalah menghubungkannya di docker build .

Saya tidak memiliki pengalaman bekerja di dalam basis kode buruh pelabuhan, tetapi ini cukup penting bagi saya sehingga saya akan mempertimbangkan untuk menggunakannya.

Besar. Di mana saya bisa mengetahui cara mengajukan proposal? Apakah ada
pedoman khusus atau haruskah saya membuka masalah saja?

Pada hari Selasa, 7 April 2015, Jessie Frazelle [email protected] menulis:

Itu adalah sesuatu yang akan kami pertimbangkan untuk diterapkan jika ada yang diterima
usul
dan bandwidth rekayasa.

Ya

Dan saya tidak berpikir ada proposal terbuka untuk ini.

Pada Sel, Apr 7, 2015 at 14:36, Zachary Adam Kaplan <
[email protected]
_e i="18">

@jfrazelle

Aku tahu kalian tidak mengabaikan kami :)

Jadi statusnya adalah:

Itu adalah sesuatu yang akan kami pertimbangkan untuk diterapkan jika ada yang diterima
usul
dan bandwidth rekayasa.

Apakah ini terdengar akurat untuk Anda?

Juga, apakah saat ini ada proposal terbuka yang membahas masalah ini?

Pada hari Selasa, 7 April 2015, Jessie Frazelle < [email protected]
_e i="31"/> menulis:

Bukannya kami tidak menginginkan fitur ini atau apa pun, saya benar-benar mengerti
menggunakan
kasus untuk sesuatu seperti ini atau rahasia dalam pembuatan kita hanya perlu
proposal dari seseorang yang bersedia untuk menerapkan dan kemudian jika disetujui,
pelaksanaan usulan.
Juga saya berbicara atas nama saya sendiri tidak semua pengelola.

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

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

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

Maksud saya seperti proposal desain
https://docs.docker.com/project/advanced-contributing/#design -proposal

Pada Selasa, 7 April 2015 pukul 14.39, Daniel Staudigel [email protected]
menulis:

Saya tidak tahu apakah saya terlalu menyederhanakan banyak hal, tetapi inilah proposal saya:

SSHAGENT: meneruskan # default untuk diabaikan

Jika disetel, selama pembuatan, soket & variabel lingkungan terkait adalah
terhubung ke wadah, di mana mereka dapat digunakan. Potongan mekanis
ini sudah ada dan berfungsi, ini hanya masalah menghubungkan
mereka dalam build buruh pelabuhan.

Saya tidak punya pengalaman bekerja di dalam basis kode buruh pelabuhan, tapi ini
cukup penting bagi saya sehingga saya akan mempertimbangkan untuk menerimanya.

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

Ini adalah ide tingkat yang sangat tinggi, tetapi bagaimana jika alih-alih melampirkan melalui api jarak jauh buruh pelabuhan, buruh pelabuhan menjalankan daemon init, dengan daemon ssh yang dibundel, di dalam wadah?

Ini dapat digunakan untuk memecahkan sejumlah masalah.

• Daemon ini akan menjadi PID 1, dan proses container utama adalah PID 2. Ini akan menyelesaikan semua masalah dengan PID 1 mengabaikan sinyal dan container tidak dimatikan dengan benar. (#3793)
• Ini akan memungkinkan penerusan agen kunci SSH dengan bersih. (#6396)
• Daemon ini dapat membuat ruang nama tetap terbuka (#12035)
• TTY akan dibuat oleh daemon (#11462)
• ...dan mungkin banyak masalah lain yang saya lupakan.

Anda mungkin ingin melihat https://github.com/docker/docker/issues/11529 tentang
poin poin pertama

Pada Tue, Apr 7, 2015 at 14:46, Patrick Hemmer [email protected]
menulis:

Ini adalah ide tingkat yang sangat tinggi, tetapi bagaimana jika alih-alih melekat
api jarak jauh buruh pelabuhan, buruh pelabuhan menjalankan daemon init, dengan ssh . yang dibundel
daemon, di dalam wadah?

Ini dapat digunakan untuk memecahkan sejumlah masalah.

• Daemon ini akan menjadi PID 1, dan proses container utama adalah
  PID 2. Ini akan menyelesaikan semua masalah dengan PID 1 mengabaikan sinyal dan
  wadah tidak dimatikan dengan benar. (#3793
  https://github.com/docker/docker/issues/3793
• Ini akan memungkinkan penerusan agen kunci SSH dengan bersih. (#6396
  https://github.com/docker/docker/issues/6396)
• Daemon ini dapat membuat ruang nama tetap terbuka (#12035
  https://github.com/docker/docker/issues/12035
• Sebuah TTY akan dibuat oleh daemon (#11462
  https://github.com/docker/docker/issues/11462)
• ...dan mungkin banyak masalah lain yang saya lupakan.

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

11529 sama sekali tidak terkait dengan masalah PID 1.

shoot efing copy paste, sekarang saya harus mencari yang lain lagi

bukan itu yang itu, itu memperbaiki hal-hal zombie PID 1 yang saya pikir Anda maksudkan tetapi terlepas dari itu saya hanya memposting karena ini adalah segalanya

@phemmer Sepertinya Anda memiliki keahlian untuk membimbing kami dalam membuat proposal yang cerdas untuk implementasi.

Sepertinya @dts juga dan saya bersedia meluangkan waktu untuk mengerjakan ini.

@phemmer dan @dts apakah ada cara yang memungkinkan kita dapat membawa diskusi ini ke klien obrolan yang sedikit lebih real-time untuk komunikasi yang lebih mudah? Saya tersedia melalui Slack, Google Chat/Hangout, IRC dan saya akan mengunduh apa pun jika perlu.

@phemmer Sepertinya Anda memiliki keahlian untuk membimbing kami dalam membuat proposal yang cerdas untuk implementasi

Sayangnya tidak juga :-)
Saya dapat membuang ide desain, tetapi saya hanya tahu sebagian kecil dari basis kode buruh pelabuhan. Jenis perubahan ini cenderung berskala besar.

Sudah ada beberapa proposal di sini:

@phemmer disarankan

bagaimana jika alih-alih melampirkan melalui api jarak jauh buruh pelabuhan, buruh pelabuhan menjalankan daemon init, dengan daemon ssh yang dibundel, di dalam wadah?

@dts disarankan

SSHAGENT: meneruskan # default untuk diabaikan
Jika disetel, selama pembuatan, soket & variabel lingkungan terkait terhubung ke wadah, di mana mereka dapat digunakan. Potongan mekanis ini sudah ada dan berfungsi, hanya masalah menghubungkannya di docker build.

@razic menyarankan

Aktifkan pengikatan volume untuk docker build .

Yang benar-benar kami butuhkan saat ini adalah seseorang untuk menerima salah satu dari mereka sehingga kami dapat mulai mengerjakannya.

@jfrazelle Ada ide tentang bagaimana kita bisa sampai ke langkah selanjutnya? Sungguh, saya hanya mencoba menyelesaikan ini. Jelas bahwa ada banyak minat dalam hal ini. Saya bersedia memperjuangkan fitur tersebut, melihatnya sampai selesai.

Saya dapat tersedia untuk pertemuan slack/irc/Gchat/etc, saya pikir ini akan membuat segalanya sedikit lebih mudah, setidaknya untuk mengumpulkan persyaratan dan memutuskan tindakan yang masuk akal.

@dts disarankan

SSHAGENT: meneruskan # default untuk diabaikan

Ini hanya ide tentang bagaimana itu akan dikonsumsi, tidak diimplementasikan. "Init/ssh daemon" adalah ide bagaimana implementasinya. Keduanya bisa sama-sama ada.

@razic menyarankan

Aktifkan pengikatan volume untuk menjalankan buruh pelabuhan.

Sayangnya ini tidak akan berhasil. Dengan asumsi ini berarti docker build , dan bukan docker run , yang sudah mendukung volume mount, di sana klien dapat berada jauh (boot2docker adalah salah satu contoh yang menonjol). Pengikatan volume hanya berfungsi ketika klien berada di Host yang sama dengan daemon buruh pelabuhan.

@razic silakan lihat tautan ini tentang proposal desain ... itu bukan proposal https://docs.docker.com/project/advanced-contributing/#design -proposal

@phemmer

Saya gagal memahami dengan tepat mengapa ini tidak berhasil. docker-compose berfungsi dengan pemasangan volume terhadap klaster swarm . Jika file/folder tidak ada di sistem host, perilakunya sama seperti jika Anda menjalankan -v dengan jalur yang tidak ada.

@jfrazelle Mengerti.

Jika file/folder tidak ada di sistem Host, itu memberikan perilaku yang sama seperti jika Anda menjalankan -v dengan jalur yang tidak ada di buruh pelabuhan lokal.

Saya tidak yakin saya mengikuti maksud Anda. Bagaimana perilaku itu membantu masalah ini?
Jika saya memiliki agen kunci ssh yang mendengarkan /tmp/ssh-UPg6h0 di mesin lokal saya, dan saya memiliki buruh pelabuhan yang berjalan di mesin jarak jauh, dan memanggil docker build , agen kunci ssh lokal itu tidak dapat diakses oleh daemon buruh pelabuhan. Pemasangan volume tidak akan mendapatkannya, dan wadah docker build tidak akan memiliki akses ke kunci ssh.

Dari level tinggi, saya hanya melihat 2 cara untuk menyelesaikan ini:

1. Proksi soket agen kunci ssh:

Daemon buruh pelabuhan membuat soket domain unix di dalam wadah dan setiap kali sesuatu terhubung ke sana, itu mem-proksi koneksi itu kembali ke klien yang sebenarnya menjalankan perintah docker build .

Ini mungkin sulit untuk diterapkan karena mungkin ada sejumlah koneksi yang berubah-ubah ke soket domain unix di dalam wadah. Ini berarti bahwa daemon & klien buruh pelabuhan harus mem-proksi sejumlah koneksi yang berubah-ubah, atau daemon harus dapat berbicara dengan protokol agen ssh, dan menggandakan permintaan.

Namun sekarang karena API jarak jauh buruh pelabuhan mendukung soket web (tidak pada saat masalah ini dibuat), ini mungkin tidak terlalu sulit.

2. Mulai daemon SSH yang sebenarnya

Alih-alih meretas agen ssh, gunakan koneksi ssh aktual dari klien ke dalam wadah. Klien buruh pelabuhan akan memiliki klien ssh yang dibundel, atau akan memanggil ssh ke dalam wadah jarak jauh.
Ini akan menjadi perubahan skala yang jauh lebih besar karena akan menggantikan cara penerapan pada wadah. Tetapi itu juga akan meringankan buruh pelabuhan dari keharusan menangani itu, dan bermigrasi ke protokol standar.
Ini juga berpotensi untuk memecahkan masalah lain (seperti yang disebutkan di sini ).

Jadi pada akhirnya banyak perubahan skala yang lebih besar, tetapi mungkin merupakan solusi yang lebih tepat.
Meskipun secara realistis, karena skalanya, saya ragu ini akan terjadi.

@phemmer

Saya tidak yakin saya mengikuti maksud Anda. Bagaimana perilaku itu membantu masalah ini?

Karena kasus penggunaan yang paling umum untuk ini adalah orang yang membuat gambar dengan dependensi yang dihosting di repositori pribadi yang memerlukan otentikasi SSH.

Anda membangun gambar pada mesin yang memiliki kunci SSH. Sesederhana itu.

Jika saya memiliki agen kunci ssh yang mendengarkan di /tmp/ssh-UPg6h0 di mesin lokal saya, dan saya menjalankan buruh pelabuhan di mesin jarak jauh, dan memanggil build buruh pelabuhan, agen kunci ssh lokal itu tidak dapat diakses oleh daemon buruh pelabuhan.

Aku tahu. Siapa peduli? Saya akan menjalankan docker build pada mesin yang memiliki akses ke soket auth.

Apa yang saya coba katakan adalah.... docker-compose memungkinkan Anda untuk menggunakan perintah volume terhadap cluster swarm , terlepas dari apakah file tersebut benar-benar ada di host atau tidak! .

Kita harus melakukan hal yang sama untuk volume mount pada build docker.

| File ada di sistem | Aksi |
| :-- | :-- |
| Ya | Gunung |
| Tidak | Tidak ada (sebenarnya ini mencoba untuk me-mount tetapi membuat folder kosong jika file/folder tidak ada, Anda dapat memverifikasi ini dengan menjalankan docker run -v /DOES_NOT_EXIST:/DOES_NOT_EXIST ubuntu ls -la /DOES_NOT_EXIST ) |

Salah satu konsep di balik swarm adalah membuat model multi-host transparan.

Ada baiknya kita memikirkan buruh pelabuhan jarak jauh, tetapi itu tidak terlalu penting.

Kita hanya perlu menyalin perilaku untuk pemasangan volume untuk docker build dengan cara yang sama persis seperti yang kita lakukan untuk docker run .

Dari https://github.com/docker/compose/blob/master/SWARM.md :

Hal utama yang menghentikan aplikasi multi-kontainer agar tidak bekerja dengan mulus di Swarm adalah membuat mereka berbicara satu sama lain: mengaktifkan komunikasi pribadi antara kontainer di host yang berbeda belum diselesaikan dengan cara yang tidak mudah diretas.

Jangka panjang, jaringan dirombak sedemikian rupa sehingga lebih cocok dengan model multi-host. Untuk saat ini, penampung tertaut secara otomatis dijadwalkan pada host yang sama.

@phemmer Saya pikir orang mungkin memikirkan solusi untuk masalah yang Anda jelaskan. Masalah yang Anda gambarkan terdengar seperti https://github.com/docker/docker/issues/7249 yang terpisah.

Jika kami mengambil pendekatan saya: hanya mengizinkan pemasangan volume di docker build (terlepas dari apakah file yang Anda coba pasang sebenarnya ada di system , maka kami dapat menutup masalah ini. dan mulai mengerjakan https://github.com/ docker/docker/issues/7249 yang akan memperluas perilaku fitur ini untuk bekerja dengan daemon buruh pelabuhan jarak jauh yang tidak memiliki file lokal.

@ cpuguy83 Sebelum saya membuat proposal, saya melihat #7133 dan memperhatikan bahwa itu terlihat terkait langsung.

Bisakah Anda menambahkan beberapa kata di sini? Apakah #7133 sebenarnya terkait dengan saran saya untuk memperbaiki masalah ini, yaitu mengizinkan docker build untuk mendukung volume.

@razic Ini terkait dengan fakta bahwa VOLUME /foo sebenarnya membuat volume dan memasangnya ke dalam wadah selama pembuatan, yang umumnya tidak diinginkan.

Saya juga akan mengatakan proposal berdasarkan penggunaan bind-mounts untuk memasukkan file ke dalam wadah build mungkin tidak akan terbang.
Lihat #6697

Menjalankan -v dengan docker build dapat memiliki jalur eksekusi kode yang berbeda.
Alih-alih membuat volume dan memasangnya selama pembuatan, kami dapat mempertahankan
perilaku saat ini yang volume di dockerfiles tidak direferensikan. Dan
alih-alih hanya bertindak -v saat dijalankan menggunakan argumen ke CLI.

Pada hari Rabu, 8 April 2015, Brian Goff [email protected] menulis:

@razic https://github.com/razic Ini terkait dengan fakta bahwa VOLUME
/foo sebenarnya membuat volume dan memasangnya ke dalam wadah selama
membangun, yang umumnya tidak diinginkan.

Saya juga akan mengatakan proposal berdasarkan penggunaan bind-mounts untuk memasukkan file
membangun kontainer mungkin tidak akan terbang.
Lihat #6697 https://github.com/docker/docker/pull/6697

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

@ cpuguy83 Terima kasih atas klarifikasinya.

6697 Juga tidak akan terbang karena sudah ditutup dan #10310 praktis adalah penipuan #6697.

+1, saya baru saja mencapai ini hari ini ketika mencoba membuat gambar untuk aplikasi Rails yang menggunakan Bower untuk menginstal dependensi sisi klien. Terjadi bahwa salah satu dependensi menunjuk ke [email protected]:angular/bower-angular-i18n.git dan karena git gagal di sana, bower gagal, dan pembuatan gambar juga gagal.

Saya sangat suka apa yang dilakukan gelandangan btw. Dengan konfigurasi forward_agent tunggal di Vagrantfile, ini diselesaikan untuk tamu gelandangan. Bisakah Docker mengimplementasikan sesuatu seperti ini?

Juga, sebagai catatan tambahan, ini terjadi saat membangun gambar. Adakah yang tahu solusi yang ada?

Solusi saya, adalah membuat pasangan kunci RSA baru, mengatur kunci pub di github (tambahkan sidik jari), dan tambahkan kunci pribadi ke gambar Docker:

ADD keys/docker_rsa /srv/.ssh/id_rsa

Saya ingin menghindari ini, tetapi saya kira ini dapat diterima untuk saat ini. Ada saran lain yang dihargai!

Saya tidak yakin siapa yang telah membunuh lebih banyak anak anjing. Anda karena melakukan itu, atau Docker karena belum memberi Anda cara yang lebih baik.

Bagaimanapun saya akan mengajukan proposal akhir pekan ini mungkin. @ cpuguy83 benar bahwa orang setidaknya memikirkan hal ini dan mendiskusikan solusi yang mungkin. Jadi pada titik ini hanya masalah kita menyetujui sesuatu dan meminta seseorang untuk mengerjakannya. Saya benar-benar ingin mengerjakannya karena itu sebenarnya salah satu keluhan terbesar saya dengan Docker saat ini.

@razic Ini adalah kasus penggunaan yang cukup umum, jadi terima kasih telah

@fullofcaffeine Saya tidak 100% yakin bagaimana Docker bekerja secara internal tetapi saya pikir kecuali jika dilakukan dalam satu perintah RUN (yang tidak mungkin dengan solusi Anda) maka riwayat gambar mempertahankan kunci SSH.

@razic poin bagus.

Untuk mengatasi batasan ini, kami telah bermain-main dengan ide mengunduh kunci pribadi (dari server HTTP lokal), menjalankan perintah yang memerlukan kunci dan mereka menghapus kunci setelahnya.

Karena kami melakukan semua ini dalam satu RUN , tidak ada yang di-cache dalam gambar. Berikut tampilannya di Dockerfile:

RUN ONVAULT npm install --unsafe-perm

Implementasi pertama kami seputar konsep ini tersedia di https://github.com/dockito/vault

Satu-satunya kelemahan adalah mengharuskan server HTTP berjalan, jadi tidak ada hub Docker yang dibuat.

Biarkan aku tahu apa yang kamu pikirkan :)

+1
akan senang melihat ini diimplementasikan, ini akan membantu menyiapkan wadah untuk lingkungan pengembangan

+1, hanya perlu diteruskan ssh-agent dengan boot2dock

Kami akhirnya melakukan proses 3 langkah untuk mengatasi batasan ini:

1. buat wadah buruh pelabuhan tanpa dependensi yang diperlukan SSH, tambahkan sumber di langkah terakhir
2. pasang sumber melalui volume bersama, ditambah SSH_AUTH_SOCK melalui volume bersama dan jalankan langkah pembuatan, tulis keluaran yang memerlukan ssh (misalnya, permata ruby ​​yang dihosting github) kembali ke volume bersama
3. jalankan kembali docker build, yang akan memicu kembali sumber add, karena permata sekarang berada di direktori sumber

Hasilnya adalah gambar buruh pelabuhan dengan dependensi yang ditarik melalui SSH-auth yang tidak pernah memiliki kunci SSH di dalamnya.

Saya membuat skrip untuk mengaktifkan penerusan agen ssh untuk docker run di lingkungan boot2docker di OSX dengan sedikit kerumitan. Saya tahu itu tidak menyelesaikan masalah build, tetapi mungkin berguna untuk beberapa orang:

https://Gist.github.com/rcoup/53e8dee9f5ea27a51855

Apakah agen kunci Forward ssh bekerja dengan layanan seperti layanan Kontainer Amazon EC 2? Tampaknya bagi saya bahwa ini akan memerlukan perangkat lunak khusus yang mungkin tidak tersedia di semua platform atau PaaS yang Anda gunakan untuk menyebarkan wadah Anda.

Diperlukan solusi yang lebih umum, bekerja untuk semua.

Saat ini, saya menggunakan variabel Lingkungan. Skrip bash mendapatkan variabel kunci pribadi (dan host yang dikenal) dan mencetaknya ke file id_rsa dan known_hosts. Ini berhasil, tetapi saya belum mengevaluasi implikasi keamanan dari solusi semacam itu.

FWIW, saya telah menemukan bahwa ssh-agent dan berbagi volume dalam wadah berfungsi dengan baik dengan sedikit kesalahan:

https://github.com/whilp/ssh-agent

Akan sangat bagus untuk memiliki dukungan kelas satu untuk ini.

Penting untuk membedakan apa yang berfungsi di _run_ vs _build_. Solusi @whilp bekerja sangat baik di _run_ tetapi tidak berfungsi di _build_ karena Anda tidak dapat mengakses volume buruh pelabuhan lain selama _build_. Karenanya mengapa tiket ini masih sakit, sakit terbuka.

@rvowls ya, setuju. Saya menyatukan sesuatu untuk menghasilkan wadah melalui urutan panggilan run/commit (yaitu, tanpa Dockerfiles); itu masuk akal untuk kasus penggunaan khusus saya, tetapi dukungan umum (termasuk waktu pembuatan) untuk sesuatu seperti penerusan agen akan sangat membantu.

Apakah IP untuk menjalankan container termasuk dalam /etc/hosts selama build? Jika demikian, salah satu solusinya mungkin dengan memulai wadah yang menyajikan kunci, lalu menggulungnya selama pembuatan.

Anda semua mungkin tertarik untuk mengetahui bahwa saya telah membuat blog tentang cara menggunakan agen SSH Anda selama docker build - http://aidanhs.com/blog/post/2015-10-07-dockerfiles-reproducibility- tipuan/#_streamlining_your_experience_using_an_ssh_agent

Anda hanya perlu memulai satu wadah. Setelah dimulai, akses agen SSH akan bekerja dengan sempurna hanya dengan 3 baris tambahan di Dockerfile Anda - tidak perlu lagi mengekspos kunci Anda ke container.

Beberapa peringatan: Anda memerlukan Docker >= 1.8, dan itu tidak akan berfungsi pada build otomatis Docker Hub (jelas). Harap baca juga catatan tentang keamanan! Jangan ragu untuk mengangkat masalah di repositori sshagent github yang saya tautkan di pos jika Anda memiliki masalah.

Saya juga telah memecahkan masalah ini dengan cara yang mirip dengan @aidanhs - dengan menarik rahasia yang diperlukan melalui subnet buruh pelabuhan lokal, dan kemudian menghapusnya sebelum snapshot sistem file terjadi. Wadah yang sedang berjalan menyajikan rahasia, yang ditemukan oleh klien menggunakan siaran UDP.
https://github.com/mdsol/docker-ssh-exec

Apakah ada kemajuan dalam mewujudkan hal ini? Saya tidak dapat mengikat-mount direktori ~/.ssh Host karena izin dan kepemilikan menjadi kacau.

Bukankah ini dapat dipecahkan dengan mengizinkan pengikatan mount untuk memaksa uid/gid dan izin tertentu?

@atrauzzi bind-mounts tidak dapat memaksa uid/gid/permissions.
Dapat melakukan ini melalui FUSE (mis. bindfs), tetapi tidak hanya dengan pengikatan biasa.

@ cpuguy83 Itu benar-benar mulai membawa saya ke jalan yang tidak ingin saya tangani. Terutama ketika saya menggunakan host berbasis Windows.

Apakah tidak ada opsi ramah pengguna di sini? Saya merasa ada masalah di sini yang hanya ditunda.

@atrauzzi Memang, itu bukan masalah yang mudah untuk diselesaikan dalam waktu dekat (tidak mulus juga).

+1 ini adalah pemblokir besar untuk Dockerfile aplikasi Node.js yang sederhana. Saya telah mengerjakan banyak aplikasi Node, dan saya jarang melihat aplikasi yang tidak memiliki repo Github pribadi sebagai ketergantungan NPM.

Sebagai solusinya @apeace , Anda dapat mencoba menambahkannya sebagai git submodule ke git repo Anda. Dengan begitu mereka berada dalam konteks dan Anda bisa menambahkannya selama build dan jika Anda ingin benar-benar bersih, hapus atau abaikan file .git di masing-masing file. Dalam build buruh pelabuhan, mereka hanya dapat diinstal menggunakan direktori lokal. Jika mereka perlu menjadi git repo yang lengkap untuk beberapa alasan, pastikan file .git tidak ada di build buruh pelabuhan dan tambahkan .git/modules/<repo> sebagai <path>/<repo>/.git . Itu akan memastikan mereka adalah repo normal seolah-olah mereka dikloning.

Terima kasih atas saran itu @jakirkham , tetapi kami telah menggunakan repo pribadi sebagai ketergantungan NPM begitu lama, saya tidak ingin merusak alur kerja normal npm install .

Untuk saat ini, kami memiliki solusi yang berhasil tetapi hanya menjijikkan. Kita punya:

• Membuat pengguna & tim Github yang memiliki akses hanya baca ke repo yang kami gunakan sebagai dependensi NPM
• Mengkomit kunci pribadi pengguna itu ke repo kami di mana kami memiliki Dockerfile kami
• Di Dockerfile, alih-alih RUN npm install kita lakukan RUN GIT_SSH='/code/.docker/git_ssh.sh' npm install

Di mana git_ssh.sh adalah skrip seperti ini:

#!/bin/sh
ssh -o StrictHostKeyChecking=no -i /code/.docker/deploy_rsa "$@"

Ini berfungsi, tetapi meneruskan agen kunci ssh akan jauh lebih baik, dan jauh lebih sedikit pekerjaan pengaturan!

:+1:
Tidak dapat dipercaya bahwa permintaan fitur ini masih belum diterapkan karena di sini banyak kasus penggunaan di mana orang memerlukan akses dari repo pribadi selama waktu pembuatan.

Saya mencoba membuat wadah untuk berbagai lingkungan pengembangan sistem tertanam, yang memerlukan akses ke repositori pribadi. Menambahkan dukungan untuk kunci ssh host akan menjadi fitur yang hebat. Metode paling populer yang terbang di SO dan halaman lain tidak aman dan selama tidak ada dukungan untuk fitur ini, lapisan dengan kunci pribadi akan menyebar.

:+1:

:+1: Sudah membutuhkan ini selamanya.

Hai @apeace , Saya tidak tahu apakah Anda telah melihatnya, tetapi saya telah berkomentar sebelumnya tentang solusi kami untuk masalah ini.

Ini adalah kombinasi dari skrip dan server web. Bagaimana menurut Anda https://github.com/dockito/vault ?

@pirelenito bukankah itu membuat kuncinya masih tersedia di dalam lapisan build? Jika demikian, tidak ada gunanya bagi kami untuk menambahkan Dockito Valut ke proses pembuatan kami--bagi saya tampaknya sama 'jenky' dengan apa yang kami lakukan sekarang. Saya menghargai sarannya!

@apeace skrip ONVAULT mengunduh kunci, menjalankan perintah Anda dan kemudian segera menghapus kunci. Karena ini semua terjadi dalam perintah yang sama, lapisan terakhir tidak akan berisi kunci.

@apeace Di Medidata, kami menggunakan alat kecil yang kami buat bernama docker-ssh-exec . Ini hanya menyisakan biner docker-ssh-exec dalam gambar build yang dihasilkan -- tidak ada rahasia. Dan itu hanya membutuhkan perubahan satu kata ke Dockerfile , jadi itu sangat "jejak rendah."

Tetapi jika Anda _benar-benar_ perlu menggunakan solusi docker-native-only, sekarang ada cara bawaan untuk melakukan ini, seperti yang dicatat dalam posting blog perusahaan . Docker 1.9 memungkinkan Anda menggunakan parameter --build-arg untuk meneruskan nilai sementara ke proses pembangunan. Anda harus dapat memasukkan kunci SSH pribadi sebagai ARG , menulisnya ke sistem file, melakukan git checkout , dan kemudian _delete_ kuncinya, semua dalam lingkup satu RUN direktif. (inilah yang dilakukan klien docker-ssh-exec ). Ini akan membuat Dockerfile jelek, tetapi seharusnya tidak memerlukan alat eksternal.

Semoga ini membantu.

@benton Kami telah menemukan solusi serupa. :)

Terima kasih @pirelenito dan @benton , saya akan memeriksa semua saran Anda!

EDIT : berikut ini _NOT_ aman, sebenarnya:

Sebagai catatan, inilah cara Anda memeriksa repo pribadi dari Github tanpa meninggalkan kunci SSH Anda di gambar yang dihasilkan.

Pertama, ganti user/repo-name di Dockerfile dengan path ke repo pribadi Anda (pastikan Anda menyimpan awalan [email protected] agar ssh digunakan untuk checkout):

FROM ubuntu:latest

ARG SSH_KEY
ENV MY_REPO [email protected]:user/repo-name.git

RUN apt-get update && apt-get -y install openssh-client git-core &&\
    mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
    ssh-keyscan github.com >/root/.ssh/known_hosts

RUN echo "$SSH_KEY" >/root/.ssh/id_rsa &&\
    chmod 0600 /root/.ssh/id_rsa &&\
    git clone "${MY_REPO}" &&\
    rm -f /root/.ssh/id_rsa

Kemudian buat dengan perintah

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

meneruskan jalur yang benar ke kunci SSH pribadi Anda.

^ dengan Docker 1.9

@benton Anda mungkin ingin melihat lebih dekat output dari docker inspect sshtest dan docker history sshtest . Saya pikir Anda akan menemukan bahwa metadata pada gambar akhir memiliki rahasia Anda bahkan jika itu tidak tersedia di dalam konteks wadah itu sendiri ...

@ljrittle Bercak yang bagus. Kuncinya memang ada jika Anda menggunakan VAR . Saya kira solusi eksternal masih diperlukan di sini.

Mungkin salah satu alasan mengapa solusi asli belum dikembangkan adalah karena beberapa solusi _sudah_ ada. Tetapi saya setuju dengan sebagian besar orang lain di sini bahwa solusi bawaan akan melayani pengguna dengan lebih baik, dan sesuai dengan filosofi "termasuk baterai" Docker.

Dari dokumen...

Catatan: Tidak disarankan menggunakan variabel waktu pembuatan untuk meneruskan rahasia seperti kunci github, kredensial pengguna, dll.

( https://docs.docker.com/engine/reference/builder/#arg )

Saya tidak berpikir jalur ke file berlaku untuk ini, catatannya adalah tentang membiarkan kata sandi/token yang terlihat biasa di log konsol Anda.

Saya tidak mengikuti @jcrombez. Contohnya adalah meneruskan kunci ssh sebagai variabel melalui ARG . Jadi, itu berlaku.

Dalam hal risiko keamanan ini sangat berbeda:

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

dari ini:

docker build --tag=sshtest --build-arg SSH_KEY="mykeyisthis" .

jika seseorang menemukan log terminal Anda, konsekuensinya tidak sama.
tetapi saya bukan ahli keamanan, ini mungkin masih berbahaya karena beberapa alasan lain yang tidak saya ketahui.

Di baris perintah, saya kira.

Namun, seperti yang ditunjukkan @ljrittle dan @benton mengakui, cara apa pun yang Anda gunakan --build-arg / ARG akan dilakukan di build. Jadi memeriksanya akan mengungkapkan informasi tentang kuncinya. Keduanya meninggalkan status di wadah buruh pelabuhan terakhir dan keduanya mengalami kerentanan yang sama pada akhirnya. Karenanya, mengapa buruh pelabuhan merekomendasikan untuk tidak melakukan ini.

_POLONGAN PENGGUNA_

_Cara terbaik untuk mendapatkan pemberitahuan tentang pembaruan adalah dengan menggunakan tombol _Berlangganan_ di halaman ini._

Tolong jangan gunakan komentar "+1" atau "Saya juga punya ini" pada masalah. Kami secara otomatis
kumpulkan komentar-komentar itu untuk membuat utas singkat.

Orang-orang yang tercantum di bawah telah mendukung masalah ini dengan meninggalkan komentar +1:

@fletcher91
@benlemasurier
@dmuso
@probepark
@saada
@ianAndrewClark
@jakirkham
@galindro
@luisguilherme
@akurkin
@allardhoeve
@SevaUA
@sankethkatta
@kouk
@cliffxuan
@kotlas92
@taion

_POLONGAN PENGGUNA_

_Cara terbaik untuk mendapatkan pemberitahuan tentang pembaruan adalah dengan menggunakan tombol _Berlangganan_ di halaman ini._

Tolong jangan gunakan komentar "+1" atau "Saya juga punya ini" pada masalah. Kami secara otomatis
kumpulkan komentar-komentar itu untuk membuat utas singkat.

Orang-orang yang tercantum di bawah telah mendukung masalah ini dengan meninggalkan komentar +1:

@parknicker
@dursk
@adambiggs

Dalam hal risiko keamanan ini sangat berbeda:

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

terlepas dari riwayat bash Anda, mereka persis sama; ada banyak tempat di mana informasi itu bisa berakhir.

Misalnya, pertimbangkan bahwa permintaan API dapat dicatat di server;

Ini daemon log untuk docker build --tag=sshtest --build-arg SSH_KEY="fooobar" .

DEBU[0090] Calling POST /v1.22/build
DEBU[0090] POST /v1.22/build?buildargs=%7B%22SSH_KEY%22%3A%22fooobar%22%7D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&memory=0&memswap=0&rm=1&shmsize=0&t=sshtest&ulimits=null
DEBU[0090] [BUILDER] Cache miss: &{[/bin/sh -c #(nop) ARG SSH_KEY]}
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] Skipping excluded path: .wh..wh.aufs
DEBU[0090] Skipping excluded path: .wh..wh.orph
DEBU[0090] Applied tar sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef to 91f79150f57d6945351b21c9d5519809e2d1584fd6e29a75349b5f1fe257777e, size: 0
INFO[0090] Layer sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef cleaned up

_POLONGAN PENGGUNA_

_Cara terbaik untuk mendapatkan pemberitahuan tentang pembaruan adalah dengan menggunakan tombol _Berlangganan_ di halaman ini._

Tolong jangan gunakan komentar "+1" atau "Saya juga punya ini" pada masalah. Kami secara otomatis
kumpulkan komentar-komentar itu untuk membuat utas singkat.

Orang-orang yang tercantum di bawah telah mendukung masalah ini dengan meninggalkan komentar +1:

@cj2

Saya mencoba untuk mengemas aplikasi Ruby/rak sederhana. Gemfile mereferensikan beberapa permata pribadi. Saat bundle install dimulai dan mencoba mengakses repo pribadi, saya mulai mendapatkan kesalahan ini

Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Saya dapat mengatasinya tetapi tidak tanpa mengekspos kunci pribadi saya. Itu tidak akan berhasil. Harap aktifkan penerusan autentikasi ssh.

+1 untuk penerusan ssh selama pembuatan. Tidak dapat menggunakan go get dengan repo pribadi karena itu ;(

+1 untuk mengaktifkan kasus penggunaan ini dengan cara yang aman

_POLONGAN PENGGUNA_

_Cara terbaik untuk mendapatkan pemberitahuan tentang pembaruan adalah dengan menggunakan tombol _Berlangganan_ di halaman ini._

Tolong jangan gunakan komentar "+1" atau "Saya juga punya ini" pada masalah. Kami secara otomatis
kumpulkan komentar-komentar itu untuk membuat utas singkat.

Orang-orang yang tercantum di bawah telah mendukung masalah ini dengan meninggalkan komentar +1:

@lukad

Hanya membaca diskusi yang sangat menarik ini, saya bertanya-tanya apakah solusi sederhana dapat menyelesaikan masalah ini. Di luar kepala saya, saya berpikir, opsi di Dockerfile untuk hanya dapat mengecualikan/mengabaikan direktori/file internal tertentu saat mengambil snapshot. Akan seberapa sulit itu?

yaitu

KECUALI .ssh

Saya pikir itu akan berlaku di semua langkah yang mengikuti, jadi jika Anda menempatkannya setelah FROM maka Anda dapat menambahkan kunci Anda sebanyak yang Anda suka dan membangun seperti biasa dan tidak perlu khawatir tentang kunci yang secara tidak sengaja berakhir di gambar Anda (diberikan Anda mungkin perlu menambahkannya di setiap langkah yang memerlukannya, tetapi Anda tidak perlu khawatir akan berakhir di gambar)

Saran @benton berfungsi dengan baik, dan daemon buruh pelabuhan hanya akan mencatat kunci id_rsa jika dalam mode debug.

Cara yang lebih manis untuk mengekspos kunci Anda selama pembuatan adalah:

# Dockerfile
ARG SSH_KEY
RUN eval `ssh-agent -s` > /dev/null \
    && echo "$SSH_KEY" | ssh-add - \
    && git clone [email protected]:private/repository.git

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" .

Ha, meskipun itu memang hanya duduk di sana jika Anda melihat docker inspect my_tag .. jadi tidak yakin apa nilai sebenarnya dari boot-arg, selain sedikit lebih rapi dari ENV.

Dan, jika Anda memiliki kata sandi pada kunci id_rsa, saya kira Anda bisa menjadi manusia yang jahat dan melakukan:

# Dockerfile
ARG SSH_KEY
ARG SSH_PASS
RUN eval `ssh-agent -s` > /dev/null \
    && echo "echo $SSH_PASS" > /tmp/echo_ps && chmod 700 /tmp/echo_ps \
    && echo "$SSH_KEY" | SSH_ASKPASS=/tmp/echo_ps DISPLAY= ssh-add - \
    && git clone [email protected]:private/repository.git
    && rm /tmp/echo_ps

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" --build-arg SSH_PASS=<bad_idea> .

Tentu saja, sulit untuk merasionalisasi bahwa menjadi ide yang bagus bahkan dari jarak jauh.. tapi kita semua manusia, kurasa.

Memang, semua alasan terbesar untuk melakukan ini tampaknya adalah karena orang-orang yang melakukan "instal bundel" atau "ambil" terhadap repositori pribadi selama pembuatan..

Saya akan mengatakan hanya vendor dependensi Anda dan TAMBAHKAN seluruh proyek .. tetapi, terkadang hal-hal perlu dilakukan sekarang.

@SvenDowideit @thaJeztah Apakah ada solusi untuk masalah ini? Saya mencoba mengikuti utas tetapi antara menutup dan membuka utas lain dan banyak pendapat, saya tidak tahu apa yang akan dilakukan tim Docker atau kapan.

Yang terbaik, tetapi perlu implementasi?

Docker build menggunakan ssh-agent dalam build untuk mem-proxy ke ssh Host Anda dan kemudian menggunakan kunci Anda tanpa harus mengetahuinya!

Bagi siapa saja yang baru belajar tentang proxy ssh-agent: github to the rescue

ide asli @phemmer .

@yordis Saya rasa belum ada solusi "hebat" di utas yang tersedia secara gratis.

Komentar dari docker/docker-py#980 ini tampaknya menunjukkan bahwa jika Anda menyalin kunci ssh Anda ke direktori kunci pengguna root di sistem Host Anda, daemon akan menggunakan kunci tersebut. Namun saya pemula yang gila dalam hal ini sehingga orang lain mungkin dapat mengklarifikasi.

Oke, tapi bukan yang terbaik

Melewati kunci dengan build args docker 1.8.
Peringatan .

Pasti Ide Buruk

Banyak orang juga merekomendasikan di sini untuk menambahkan kunci sementara ke konteks build dan kemudian dengan cepat menghapusnya. Kedengarannya sangat berbahaya karena jika kunci merayap ke salah satu komit, siapa pun yang menggunakan wadah dapat mengakses kunci itu dengan memeriksa komit tertentu.

Kenapa ini belum kemana-mana?

Dibutuhkan proposal desain, masalah ini _cah_- _berantakan_ dan ide-ide hanya samar-samar saat ini. Detail implementasi aktual hilang dalam kabut "bagaimana jika kami melakukan x" dan +1. Untuk mengatur dan melanjutkan fitur yang sangat dibutuhkan ini, mereka yang memiliki solusi yang memungkinkan harus membuat file . . .

proposal desain

dan kemudian referensi masalah ini.

Saya punya beberapa berita tentang masalah ini.

Di DockerCon minggu lalu, kami didorong untuk membawa pertanyaan tersulit kami ke paviliun "Tanyakan Para Pakar" Docker, jadi saya pergi dan mengobrol singkat dengan seorang insinyur yang cerdas dan ramah dengan judul Solusi Arsitek yang menggembirakan. Saya memberinya ringkasan singkat tentang masalah ini, yang saya harap saya sampaikan secara akurat, karena dia meyakinkan saya bahwa ini dapat dilakukan dengan _only_ docker-compose ! Detail dari apa yang dia usulkan melibatkan pembangunan multi-tahap -- mungkin untuk mengakumulasi dependensi dalam konteks yang berbeda dari pembuatan aplikasi akhir -- dan tampaknya melibatkan penggunaan volume data pada waktu pembuatan.

Sayangnya, saya tidak berpengalaman dengan docker-compose, jadi saya tidak bisa mengikuti semua detailnya, tetapi dia meyakinkan saya bahwa jika saya menulis kepadanya dengan masalah yang tepat, dia akan merespons dengan solusi. Jadi saya menulis apa yang saya harap adalah email yang cukup jelas , yang mencakup referensi ke masalah GitHub terbuka ini. Dan saya mendengar kabar darinya pagi ini, dengan keyakinan bahwa dia akan menjawab ketika dia menemukan sesuatu.

Saya yakin dia sangat sibuk, jadi saya tidak akan mengharapkan sesuatu segera, tetapi saya menemukan ini menggembirakan, sejauh dia memahami masalahnya, dan siap untuk menyerangnya hanya dengan toolset asli buruh pelabuhan.

@benton Saya menggunakan konfigurasi docker-

version: '2'
services:
  serviceName:
     volumes:
      - "${SSH_AUTH_SOCK}:/tmp/ssh-agent"
    environment:
      SSH_AUTH_SOCK: /tmp/ssh-agent

Pastikan bahwa ssh-agent dimulai pada mesin host dan mengetahui tentang kunci (Anda dapat memeriksanya dengan perintah ssh-add -L).

Harap dicatat bahwa Anda mungkin perlu menambahkan

Host *
  StrictHostKeyChecking no

ke .ssh/config.

Hai @WoZ! terima kasih atas jawabannya, terlihat cukup sederhana jadi saya akan mencobanya :)

Saya punya pertanyaan, bagaimana Anda bisa menggunakan ini dengan build otomatis di hub buruh pelabuhan? Sejauh yang saya sekarang tidak ada cara untuk menggunakan file penulisan di sana :(

@garcianavalon bekerja dengan baik, tapi itu hanya untuk run , bukan build . Belum bekerja dengan Docker untuk Mac, meskipun tampaknya ada di daftar yang harus dilakukan.

Sunting: https://github.com/docker/for-mac/issues/410

Kami menemukan 2 solusi lagi untuk kebutuhan spesifik kami:

1) Siapkan mirror paket kami sendiri untuk npm, pypi, dll. di belakang VPN kami, dengan cara ini kami tidak memerlukan SSH.

2) Semua mesin host kami sudah memiliki akses ke repo pribadi, jadi kami mengkloning / mengunduh paket pribadi secara lokal ke mesin host, menjalankan instalasi paketnya untuk mengunduhnya, kemudian menggunakan -v untuk memetakan volume ke buruh pelabuhan, kemudian membangun buruh pelabuhan.

Kami saat ini menggunakan opsi 2).

Sejauh docker run , docker-ssh-agent-forward tampaknya memberikan solusi yang elegan dan berfungsi di seluruh Docker untuk Mac/Linux.

Mungkin masih merupakan ide yang baik untuk MENYALIN file known_hosts dari Host alih-alih membuatnya dalam wadah (kurang aman), mengingat ssh-agent tampaknya tidak meneruskan host yang dikenal.

Tetapi masalah mendasar dengan menarik dependensi pribadi selama langkah docker run adalah melewati cache build docker, yang bisa sangat signifikan dalam hal waktu pembuatan.

Salah satu pendekatan untuk mengatasi batasan ini adalah dengan md5/tanggal deklarasi ketergantungan build Anda (misalnya package.json ), dorong hasilnya ke gambar dan gunakan kembali gambar yang sama jika file tidak berubah. Menggunakan hash dalam nama gambar akan memungkinkan caching beberapa status. Itu harus dikombinasikan dengan intisari gambar pra-instal juga.

Ini harus lebih kuat daripada solusi @aidanhs untuk membangun server, meskipun saya masih harus mengujinya dalam skala besar.

Ini harus lebih kuat daripada solusi @aidanhs untuk membangun server, meskipun saya masih harus mengujinya dalam skala besar.

Solusi spesifik saya tidak berfungsi sejak 1.9.0 - ternyata fitur yang diperkenalkan di 1.8.0 yang saya andalkan tidak disengaja dan karenanya dihapus.

Meskipun prinsip solusi saya tetap baik-baik saja (itu hanya mengharuskan Anda memiliki server DNS dari mesin Anda yang a) mesin Anda gunakan dan b) Anda dapat menambahkan entri ke lokasi yang sesuai), saya tidak bisa mengatakan saya akan dengan antusias merekomendasikannya lagi.

Terima kasih atas info tambahannya @aidanhs!

Beberapa pembaruan mengenai solusi yang saya usulkan: hash sebenarnya tidak perlu digabungkan karena hash dari gambar dasar setelah menambahkan file deklarasi dependensi dapat dengan mudah digunakan. Selain itu, lebih baik hanya memasang file known_host sebagai volume, karena ssh-agent hanya dapat digunakan saat runtime -- dan lebih aman karena berisi daftar semua host yang Anda sambungkan.

Saya menerapkan solusi lengkap untuk node/npm dan dapat ditemukan di sini dengan dokumentasi dan contoh terperinci: https://github.com/iheartradio/docker-node

Tentu saja, prinsip-prinsip tersebut dapat diperluas untuk kerangka kerja lain.

Masalah yang sama di sini, bagaimana seseorang membangun sesuatu, di mana sesuatu itu memerlukan kredensial SSH untuk memeriksa dan membangun sejumlah proyek pada waktu pembuatan, di dalam wadah buruh pelabuhan, tanpa menulis kredensial ke gambar atau gambar dasar.

https://github.com/bibendi/dip#dip -ssh

Kami mengatasi ini dengan memiliki proses pembuatan 2 langkah. Gambar "build" yang berisi dependensi source/keys/build dibuat. Setelah itu dibangun, itu dijalankan untuk mengekstrak hasil build menjadi tarfile yang kemudian ditambahkan ke gambar "deploy". Gambar build kemudian dihapus dan yang dipublikasikan hanyalah gambar "deploy". Ini memiliki efek samping yang bagus untuk menjaga ukuran wadah/lapisan tetap rendah.

@binarytemple-bet365 lihat https://github.com/iheartradio/docker-node untuk contoh ujung ke ujung yang melakukan hal itu. Saya menggunakan lebih dari dua langkah karena saya menggunakan wadah layanan ssh, pra-instal (gambar dasar hingga sebelum menginstal dependensi pribadi), instal (status wadah setelah instalasi runtime dari dependensi pribadi) dan pasca-instal (menambahkan perintah yang Anda miliki setelah instalasi dependensi pribadi) untuk mengoptimalkan kecepatan dan pemisahan perhatian.

Lihat Rocker , ini solusi bersih.

@Sodki Saya menerima saran Anda. Ya, rocker adalah solusi yang bersih dan dipikirkan dengan matang. Lebih memalukan lagi tim buruh pelabuhan tidak akan mengambil proyek itu di bawah sayap mereka dan mencela docker build . Terima kasih.

Masih tidak ada cara yang lebih baik? :(

Apakah ada yang mencoba hal squash baru ini? https://github.com/docker/docker/pull/22641 Mungkin solusi asli buruh pelabuhan yang kami cari. Akan mencobanya sekarang dan melaporkan kembali untuk melihat bagaimana kelanjutannya.

Setelah 2+ tahun ini belum diperbaiki Tolong tim Docker melakukan sesuatu tentang itu

Sepertinya opsi --squash di 1.13 berfungsi untuk saya:
http://g.recordit.co/oSuMulfelK.gif

Saya membuatnya dengan: docker build -t report-server --squash --build-arg SSH_KEY="$(cat ~/.ssh/github_private_key)" .

Jadi ketika saya melakukannya docker history atau docker inspect , kuncinya tidak muncul.

Dockerfile saya terlihat seperti ini:

FROM node:6.9.2-alpine

ARG SSH_KEY

RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* &&\
  mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
  ssh-keyscan github.com > /root/.ssh/known_hosts

RUN echo "$SSH_KEY" > /root/.ssh/id_rsa &&\
  chmod 0600 /root/.ssh/id_rsa

COPY package.json .

RUN npm install
RUN rm -f /root/.ssh/id_rsa

# Bundle app source
COPY . .

EXPOSE 3000

CMD ["npm","start"]

@kienpham2000 , tangkapan layar Anda sepertinya masih berisi kunci - bisakah Anda memeriksa keluaran docker history dengan bendera --no-trunc dan laporkan kembali ke sini apakah kunci pribadi ditampilkan di buruh pelabuhan atau tidak sejarah?

@ryanschwartz Anda benar, --no-trunc menunjukkan semuanya, ini tidak terbang.

@kienpham2000
Hal lain yang mereka perkenalkan di rilis 1.13 adalah:

Membangun rahasia
• mengaktifkan rahasia waktu pembuatan menggunakan —bendera rahasia pembangunan
• membuat tmpfs selama pembuatan, dan memaparkan rahasia ke
membangun wadah, untuk digunakan selama membangun.
• https://github.com/docker/docker/pull/28079

Mungkin ini bisa berhasil?

Rahasia build tidak berhasil menjadi 1,13, tetapi mudah-mudahan akan berhasil di 1,14.

Pada 15 Des 2016 09:45, "Alex" [email protected] menulis:

@kienpham2000 https://github.com/kienpham2000
Hal lain yang mereka perkenalkan di rilis 1.13 adalah:

Membangun rahasia
• mengaktifkan rahasia waktu pembuatan menggunakan —bendera rahasia pembangunan
• membuat tmpfs selama pembuatan, dan memaparkan rahasia ke
membangun wadah, untuk digunakan selama membangun.
• #28079 https://github.com/docker/docker/pull/28079

Mungkin ini bisa berhasil?

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/6396#issuecomment-267393020 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AAdcPDxrctBP2TlCtXen-Y_uY8Y8B09Sks5rIXy2gaJpZM4CD4SM
.

Jadi setahun kemudian: Tidak, ini ide yang buruk. Anda TIDAK HARUS melakukan itu. Ada berbagai solusi lain. Misalnya, Github dapat menyediakan token akses. Anda dapat menggunakannya dalam file konfigurasi/variabel lingkungan dengan risiko lebih kecil karena Anda dapat menentukan tindakan mana yang diizinkan untuk setiap token.

Solusinya adalah dengan menerapkan penerusan SSH. Seperti yang dilakukan Vagrant misalnya.

Adakah yang bisa menjelaskan kepada saya mengapa begitu rumit untuk mengimplementasikannya?

@omarabid - apakah Anda membalas proposal asli Anda untuk menggunakan variabel lingkungan untuk meneruskan kunci pribadi untuk digunakan dalam Dockerfile? Tidak diragukan lagi, itu adalah praktik keamanan yang buruk.

Mengenai saran Anda untuk menggunakan token akses, mereka akan disimpan dalam lapisan dan bisa sama berbahayanya jika dibiarkan tergeletak seperti kunci SSH. Bahkan jika hanya memiliki akses baca saja, kebanyakan orang tidak ingin orang lain memiliki akses hanya baca ke repo mereka. Juga, pencabutan/rotasi/distribusi yang sering perlu dilakukan; ini sedikit lebih mudah ditangani untuk setiap pengembang dll. daripada dengan token akses "master".

Solusi rahasia pembuatan yang disebutkan beberapa komentar kembali sepertinya merupakan langkah ke arah yang benar, tetapi kemampuan untuk menggunakan agen SSH adalah yang terbaik. Mungkin seseorang dapat menggunakan agen SSH dalam kombinasi dengan rahasia pembuatan, saya tidak yakin.

Itu wajar bagi pengembang/sistem CI untuk menggunakan agen SSH selama operasi git/build. Ini jauh lebih aman daripada memiliki kunci pribadi tanpa kata sandi dan teks biasa yang harus dicabut/diganti secara massal di berbagai sistem. Juga, dengan agen SSH, tidak ada kemungkinan data kunci pribadi dikomit ke gambar. Paling buruk, variabel lingkungan/sisa SSH_AUTH_SOCK akan tertinggal di gambar.

Saya mendapatkan solusi terbaru ini tanpa menunjukkan konten kunci rahasia atau menggunakan alat buruh pelabuhan pihak ketiga tambahan (semoga brankas rahasia selama PR yang dibangun akan segera digabungkan).

Saya menggunakan aws cli untuk mengunduh kunci pribadi bersama dari S3 ke dalam repo Host saat ini. Kunci ini dienkripsi saat istirahat menggunakan KMS. Setelah kunci diunduh, Dockerfile hanya akan MENYALIN kunci itu selama proses pembuatan dan menghapusnya setelah itu, konten tidak ditampilkan di docker inspect atau docker history --no-trunc

Unduh kunci pribadi github dari S3 terlebih dahulu ke mesin Host:

# build.sh
s3_key="s3://my-company/shared-github-private-key"
aws configure set s3.signature_version s3v4
aws s3 cp $s3_key id_rsa --region us-west-2 && chmod 0600 id_rsa

docker build -t app_name .

Dockerfile terlihat seperti ini:

FROM node:6.9.2-alpine

ENV id_rsa /root/.ssh/id_rsa
ENV app_dir /usr/src/app

RUN mkdir -p $app_dir
RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* && mkdir -p /root/.ssh && ssh-keyscan github.com > /root/.ssh/known_hosts

WORKDIR $app_dir

COPY package.json .
COPY id_rsa $id_rsa
RUN npm install && npm install -g gulp && rm -rf $id_rsa

COPY . $app_dir
RUN rm -rf $app_dir/id_rsa

CMD ["start"]

ENTRYPOINT ["npm"]

@kienpham2000 , mengapa solusi ini tidak menyimpan kunci ke dalam lapisan gambar? Tindakan menyalin dan menghapus kunci dilakukan dalam perintah terpisah, jadi ada lapisan yang harus memiliki kunci.
Tim kami menggunakan solusi Anda hingga kemarin, tetapi kami menemukan solusi yang ditingkatkan:

• Kami membuat URL pra-tanda untuk mengakses kunci dengan aws s3 cli, dan membatasi akses selama sekitar 5 menit, kami menyimpan URL pra-tanda ini ke dalam file di direktori repo, lalu di dockerfile kami menambahkannya ke gambar.
• Di dockerfile kami memiliki perintah RUN yang melakukan semua langkah ini: gunakan URL pra-bernyanyi untuk mendapatkan kunci ssh, jalankan npm install, dan hapus kunci ssh.
  Dengan melakukan ini dalam satu perintah, kunci ssh tidak akan disimpan di lapisan mana pun, tetapi URL pra-tanda akan disimpan, dan ini bukan masalah karena URL tidak akan valid setelah 5 menit.

Skrip build terlihat seperti:

# build.sh
aws s3 presign s3://my_bucket/my_key --expires-in 300 > ./pre_sign_url
docker build -t my-service .

Dockerfile terlihat seperti ini:

FROM node

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    ssh -o StrictHostKeyChecking=no [email protected] || true && \
    npm install --production && \
    rm ./my_key && \
    rm -rf ~/.ssh/*

ENTRYPOINT ["npm", "run"]

CMD ["start"]

@diegocsandrim terima kasih telah menunjukkan hal itu, saya sangat menyukai solusi Anda, akan memperbarui barang-barang kami di sini. Terima kasih telah berbagi!

Saya agak baru dalam topik ini, tetapi pada dasarnya sepertinya orang mencoba memecahkan masalah yang lebih baik diselesaikan oleh PKI. Tidak semua orang harus mencoba untuk menyelamatkan masalah yang sama di mana PKI akan menjadi solusi yang lebih baik, tetapi referensi yang cukup tampaknya menunjukkan bahwa itu mungkin sesuatu yang harus dipertimbangkan.

Tampaknya menjengkelkan, tetapi pada dasarnya mungkin untuk

• buat otoritas sertifikat lokal
• memiliki proses untuk menghasilkan sertifikat
• memiliki proses untuk mengeluarkan sertifikat
• memiliki proses untuk mencabut sertifikat tersebut
• minta daemon ssh menggunakan PKI

Dan jika orang merasa ini layak, maka silakan buat dan buka sumbernya, setelah semua pekerjaan perlu dilakukan dengan baik. Saya tidak tahu apakah roumen petrov build aman dan tidak mencatat kode sumber apa pun (belum memeriksa tar), jadi saya tidak tahu seberapa aman itu.

https://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

@mehmetcodes : Memiliki PKI tidak benar-benar menyelesaikan masalah. Agar autentikasi SSH berbasis PKI berfungsi, Anda masih perlu memuat kunci pribadi ke gambar.

Kecuali Anda memiliki otoritas sertifikat lokal yang menerbitkan sertifikat yang berumur sangat pendek (misalnya kurang dari satu jam), dan Anda mencabut sertifikat segera setelah pembangunan berhasil, ini tidak aman.

Jika Anda berhasil membuat proses sertifikat yang berumur pendek, itu tidak jauh berbeda dengan hanya menggunakan kunci SSH baru yang Anda cabut segera setelah build selesai.

Oh itu bahkan lebih menyebalkan dari itu, tapi aku harus memikirkan sesuatu atau mengapa itu ada di alam liar?

https://blog.cloudflare.com/red-october-cloudflares-open-source-implementation-of-the-two-man-rule/
https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/

Saya tidak tahu, kunci temp SSH mungkin jauh lebih baik untuk sebagian besar kasus penggunaan, tetapi ada sesuatu yang mengganggu tentang setiap jalan, termasuk yang saya sarankan, terutama dalam konteks ini.

Apa pendapat Anda tentang http://blog.cloud66.com/using-ssh-private-keys-securely-in-docker-build/?

Anda biasanya hanya memasang volume dengan kunci, sebagai gantinya, tetapi itu tidak membantu kebutuhan akan solusi buruh pelabuhan untuk Mac/moby.

siapa f.. adalah moby?

@warna putih

Saya sudah sejauh ini di MacOS:

bash-3.2$ docker run -t -i -v "$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
docker: Error response from daemon: Mounts denied:
The path /var/folders/yb/880w03m501z89p0bx7nsxt580000gn/T//ssh-DcwJrLqQ0Vu1/agent.10466
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.

/var/ adalah alias, yang tampaknya diperjuangkan oleh Docker. Tetapi jika saya mengawali jalur $SSH_AUTH_SOCK dengan /private (yaitu jalur alias yang diselesaikan), maka Docker dapat membaca file tersebut, tetapi saya mendapatkan:

bash-3.2$ docker run -t -i -v "/private$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
Could not open a connection to your authentication agent.

Pada titik ini saya bertanya-tanya seberapa buruk hanya…

docker run -v ~/.ssh:/root/.ssh python:3.6 bash

?

docker build  --build-arg ssh_prv_key="$(cat ~/.ssh/id_rsa_no_pass)" --build-arg ssh_pub_key="$(cat ~/.ssh/id_rsa.pub)" --squash .

Dan kemudian di dalam file Docker:

ARG ssh_prv_key
ARG ssh_pub_key

# Authorize SSH Host
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts

# Add the keys and set permissions
RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa && \
    echo "$ssh_pub_key" > /root/.ssh/id_rsa.pub && \
    chmod 600 /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa.pub

Dan jangan lupa sertakan

RUN rm -f /root/.ssh/id_rsa /root/.ssh/id_rsa.pub

sebagai langkah terakhir.

Tangkapannya di sini adalah bahwa kunci pribadi Anda tidak boleh dilindungi kata sandi.

Masalah dengan komentar sebelumnya adalah bahwa kunci berakhir di lapisan... rm tidak akan menghapus dari lapisan sebelumnya, karena setiap baris dalam file buruh pelabuhan adalah satu lapisan..

Bukankah docker secret menyelesaikan masalah ini?
WDYT @thaJeztah

docker secret tidak (belum) tersedia selama build, dan hanya tersedia di layanan (jadi belum untuk docker run )

Saat menggunakan multi stage build, sesuatu seperti ini bisa berfungsi (mengetik di ponsel saya, jadi izinkan saya menautkan intisari yang saya buat beberapa waktu lalu); https://Gist.github.com/thaJeztah/836c4220ec024cf6dd48ffa850f07770

Saya tidak lagi terlibat dengan Docker, tetapi, bagaimana mungkin masalah ini ada untuk waktu yang lama. Saya tidak mencoba untuk memanggil tetapi daripada memahami apa upaya yang diperlukan untuk memperbaikinya karena ketika saya berurusan dengan ini, tampaknya masalah yang sangat umum bagi perusahaan mana pun yang menarik paket pribadi seperti ruby gems dari a repo pribadi.

Apakah Moby peduli dengan masalah ini? Mengapa harus begitu sulit untuk sesuatu yang tampaknya bukan masalah besar kurasa.

Sudah hampir 3 tahun

@yordis docker builder dibekukan selama satu atau dua tahun. Tim Docker menyatakan bahwa pembangun cukup baik dan mereka memfokuskan upaya mereka di tempat lain. Tapi ini hilang dan ada dua perubahan pada builder sejak itu. Tahap build squash dan mustli. Jadi rahasia buildtime mungkin sedang dalam perjalanan.

Untuk penerusan runtime ssh-agent, saya akan merekomendasikan https://github.com/uber-common/docker-ssh-agent-forward

Mengapa harus begitu sulit untuk sesuatu yang tampaknya bukan masalah besar kurasa.

@yordis membaca deskripsi teratas masalah ini, menerapkan ini jauh dari sepele; karena itu, jika seseorang memiliki proposal desain teknis untuk ini, jangan ragu untuk membuka masalah atau PR untuk didiskusikan. Perhatikan juga bahwa untuk bagian _build_, proyek buildkit telah dimulai untuk penyempurnaan builder di masa mendatang; https://github.com/moby/buildkit

@thaJeztah Saya berharap saya bisa memiliki keterampilan yang dibutuhkan tetapi saya tidak.

@villlem apakah Anda tahu peta jalan dari tim Docker?

Laporan mingguan untuk pembangun dapat ditemukan di sini; https://github.com/moby/moby/tree/master/reports/builder rahasia waktu pembuatan masih tercantum dalam laporan terbaru, tetapi dapat menggunakan bantuan

Kami menggunakan solusi @diegocsandrim tetapi dengan langkah enkripsi menengah untuk menghindari meninggalkan kunci SSH yang tidak terenkripsi di S3.

Langkah ekstra ini berarti bahwa kunci tidak dapat dipulihkan dari gambar Docker (URL untuk mengunduhnya kedaluwarsa setelah lima menit) dan tidak dapat dipulihkan dari AWS (karena dienkripsi dengan kata sandi berputar yang hanya diketahui oleh gambar buruh pelabuhan) .

Di build.sh:

BUCKET_NAME=my_bucket
KEY_FILE=my_unencrypted_key
openssl rand -base64 -out passfile 64
openssl enc -aes-256-cbc -salt -in $KEY_FILE -kfile passfile | aws s3 cp - s3://$BUCKET_NAME/$(hostname).enc_key
aws s3 presign s3://$BUCKET_NAME/$(hostname).enc_key --expires-in 300 > ./pre_sign_url
docker build -t my_service

Dan di Dockerfile:

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - | openssl enc -aes-256-cbc -d -kfile passfile > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    mkdir /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts && \
    [commands that require SSH access to Github] && \
    rm ./my_key && \
    rm ./passfile && \
    rm -rf /root/.ssh/

jika Anda menggunakan docker run Anda harus memasang .ssh Anda dengan --mount type=bind,source="${HOME}/.ssh/",target="/root/.ssh/",readonly . Readonly adalah keajaiban, itu menutupi izin normal dan ssh pada dasarnya melihat 0600 izin yang senang dengannya. Anda juga dapat bermain dengan -u root:$(id -u $USER) agar pengguna root di wadah menulis file apa pun yang dibuatnya dengan grup yang sama dengan pengguna Anda, jadi semoga Anda setidaknya dapat membacanya jika tidak sepenuhnya menulisnya tanpa harus chmod/chown .

Akhirnya.

Saya percaya masalah ini sekarang dapat diselesaikan hanya dengan docker build , dengan menggunakan build multi-tahap .
Cukup COPY atau ADD kunci SSH atau rahasia lain di mana pun Anda membutuhkannya, dan gunakan dalam pernyataan RUN sesuka Anda.

Kemudian, gunakan pernyataan FROM untuk memulai sistem file baru, dan COPY --from=builder untuk mengimpor beberapa subset direktori yang tidak menyertakan secret .

(Saya belum benar-benar mencoba ini, tetapi jika fitur berfungsi seperti yang dijelaskan ...)

@benton multi-tahap membangun berfungsi seperti yang dijelaskan, kami menggunakannya. Ini adalah pilihan terbaik untuk banyak masalah yang berbeda, termasuk yang satu ini.

Saya telah memverifikasi teknik berikut:

1. Teruskan _lokasi kunci pribadi_ sebagai Argumen Build, seperti GITHUB_SSH_KEY , ke tahap pertama dari build multi-tahap
2. Gunakan ADD atau COPY untuk menulis kunci di mana pun diperlukan untuk otentikasi. Perhatikan bahwa jika lokasi kunci adalah jalur sistem file lokal (dan bukan URL), itu harus _tidak_ berada di file .dockerignore , atau direktif COPY tidak akan berfungsi. Ini memiliki implikasi untuk gambar akhir, seperti yang akan Anda lihat di langkah 4...
3. Gunakan kunci sesuai kebutuhan. Pada contoh di bawah, kunci digunakan untuk mengautentikasi ke GitHub. Ini juga berfungsi untuk bundler Ruby dan repositori Permata pribadi. Bergantung pada seberapa banyak basis kode yang perlu Anda sertakan pada saat ini, Anda mungkin akhirnya menambahkan kunci lagi sebagai efek samping dari penggunaan COPY . atau ADD . .
4. HAPUS KUNCI JIKA PERLU . Jika lokasi kunci adalah jalur sistem file lokal (dan bukan URL), maka kemungkinan itu ditambahkan di samping basis kode ketika Anda melakukannya ADD . atau COPY . Ini mungkin _tepatnya direktori_ itu akan disalin ke gambar runtime akhir, jadi Anda mungkin juga ingin menyertakan pernyataan RUN rm -vf ${GITHUB_SSH_KEY} setelah Anda selesai menggunakan kunci.
5. Setelah aplikasi Anda sepenuhnya dibangun ke dalam WORKDIR , mulailah tahap pembangunan kedua dengan pernyataan FROM , yang menunjukkan gambar waktu proses yang Anda inginkan. Instal semua dependensi runtime yang diperlukan, lalu COPY --from=builder terhadap WORKDIR dari tahap pertama.

Berikut adalah contoh Dockerfile yang menunjukkan teknik di atas. Memberikan GITHUB_SSH_KEY Build Argument akan menguji autentikasi GitHub saat membangun, tetapi data kunci _tidak_ akan disertakan dalam gambar runtime akhir. GITHUB_SSH_KEY dapat berupa jalur sistem file (dalam direktori build Docker) atau URL yang menyajikan data kunci, tetapi kunci itu sendiri tidak boleh dienkripsi dalam contoh ini.

########################################################################
# BUILD STAGE 1 - Start with the same image that will be used at runtime
FROM ubuntu:latest as builder

# ssh is used to test GitHub access
RUN apt-get update && apt-get -y install ssh

# The GITHUB_SSH_KEY Build Argument must be a path or URL
# If it's a path, it MUST be in the docker build dir, and NOT in .dockerignore!
ARG GITHUB_SSH_KEY=/path/to/.ssh/key

  # Set up root user SSH access for GitHub
ADD ${GITHUB_SSH_KEY} /root/.ssh/id_rsa

# Add the full application codebase dir, minus the .dockerignore contents...
# WARNING! - if the GITHUB_SSH_KEY is a file and not a URL, it will be added!
COPY . /app
WORKDIR /app

# Build app dependencies that require SSH access here (bundle install, etc.)
# Test SSH access (this returns false even when successful, but prints results)
RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1 | grep -i auth

# Finally, remove the $GITHUB_SSH_KEY if it was a file, so it's not in /app!
# It can also be removed from /root/.ssh/id_rsa, but you're probably not going
# to COPY that directory into the runtime image.
RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id*

########################################################################
# BUILD STAGE 2 - copy the compiled app dir into a fresh runtime image
FROM ubuntu:latest as runtime
COPY --from=builder /app /app

Ini _mungkin_ lebih aman untuk meneruskan data kunci itu sendiri dalam Argumen Pembuatan GITHUB_SSH_KEY , daripada _lokasi_ data kunci. Ini akan mencegah penyertaan data kunci yang tidak disengaja jika disimpan dalam file lokal dan kemudian ditambahkan dengan COPY . . Namun, ini memerlukan penggunaan echo dan pengalihan shell untuk menulis data ke sistem file, yang mungkin tidak berfungsi di semua gambar dasar. Gunakan teknik mana pun yang paling aman dan paling memungkinkan untuk kumpulan gambar dasar Anda.

@jbiel Setahun lagi, dan solusi yang saya temukan adalah menggunakan sesuatu seperti Vault.

Berikut tautan dengan 2 metode (squash dan wadah perantara yang dijelaskan sebelumnya oleh @benton)

Saya hanya menambahkan catatan untuk mengatakan bahwa tidak satu pun dari pendekatan saat ini akan berfungsi jika Anda memiliki frasa sandi pada kunci ssh yang Anda gunakan karena agen akan meminta Anda untuk frasa sandi setiap kali Anda melakukan tindakan yang memerlukan akses. Saya tidak berpikir ada cara untuk mengatasi ini tanpa menyampaikan frasa kunci (yang tidak diinginkan karena sejumlah alasan)

Pemecahan.
Buat skrip bash (~/bin/docker-compose atau suka):

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

Dan di Dockerfile menggunakan socat:

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

Kemudian jalankan docker-compose build

@benton mengapa anda menggunakan RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id* ? Bukankah seharusnya RUN rm -vf /root/.ssh/id* ? Atau mungkin saya salah memahami maksud di sini.

@benton Dan juga tidak aman untuk dilakukan:

RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1

Anda harus memeriksa sidik jari

Saya memecahkan masalah ini dengan cara ini

ARGS USERNAME
ARGS PASSWORD
RUN git config --global url."https://${USERNAME}:${PASSWORD}@github.com".insteadOf "ssh://[email protected]"

kemudian membangun dengan

docker build --build-arg USERNAME=use --build-arg PASSWORD=pwd. -t service

Tetapi pada awalnya, server git pribadi Anda harus mendukung username:password clone repo.

@zeayes RUN perintah disimpan dalam riwayat wadah. Jadi kata sandi Anda terlihat oleh orang lain.

Benar; saat menggunakan --build-arg / ARG , nilai-nilai itu akan muncul di riwayat pembuatan. Mungkin _is_ menggunakan teknik ini jika Anda menggunakan build multi-tahap _dan_ memercayai host tempat gambar dibuat (yaitu, tidak ada pengguna yang tidak dipercaya yang memiliki akses ke riwayat build lokal), _dan_ tahap build menengah tidak didorong ke registri.

Misalnya, dalam contoh berikut, USERNAME dan PASSWORD hanya akan muncul di riwayat untuk tahap pertama ("pembuat"), tetapi tidak akan ada di riwayat untuk tahap terakhir;

FROM something AS builder
ARG USERNAME
ARG PASSWORD
RUN something that uses $USERNAME and $PASSWORD

FROM something AS finalstage
COPY --from= builder /the/build-artefacts /usr/bin/something

Jika hanya gambar akhir (diproduksi oleh "finalstage") yang didorong ke registri, maka USERNAME dan PASSWORD tidak akan ada di gambar itu.

_Namun_, dalam riwayat cache build lokal, variabel tersebut akan tetap ada (dan disimpan di disk dalam teks biasa).

Builder generasi berikutnya (menggunakan BuildKit ) akan memiliki lebih banyak fitur, juga terkait dengan melewati rahasia waktu build; itu tersedia di Docker 18.06 sebagai fitur eksperimental, tetapi akan keluar dari eksperimental di rilis mendatang, dan lebih banyak fitur akan ditambahkan (saya harus memeriksa apakah rahasia/kredensial sudah dimungkinkan dalam versi saat ini)

@kinnalru @thaJeztah thx, saya menggunakan build multi-tahap, tetapi kata sandinya dapat dilihat di riwayat wadah cache, thx!

@zeayes Oh! Saya melihat saya melakukan kesalahan salin/tempel; tahap terakhir tidak boleh menggunakan FROM builder .. . Berikut ini contoh lengkapnya; https://Gist.github.com/thaJeztah/af1c1e3da76d7ad6ce2abab891506e50

Komentar oleh @kinnalru ini adalah cara yang tepat untuk melakukan ini https://github.com/moby/moby/issues/6396#issuecomment -348103398

Dengan metode ini, buruh pelabuhan tidak pernah menangani kunci pribadi Anda. Dan itu juga berfungsi hari ini, tanpa ada fitur baru yang ditambahkan.

Butuh beberapa saat untuk mengetahuinya, jadi inilah penjelasan yang lebih jelas dan lebih baik. Saya mengubah kode @kinnalru untuk menggunakan --network=host dan localhost , jadi Anda tidak perlu tahu alamat ip Anda. ( intinya disini )

Ini docker_with_host_ssh.sh , itu membungkus buruh pelabuhan dan meneruskan SSH_AUTH_SOCK ke port di localhost:

#!/usr/bin/env bash

# ensure the processes get killed when we're done
trap 'kill $(jobs -p)' EXIT

# create a connection from port 56789 to the unix socket SSH_AUTH_SOCK (which is used by ssh-agent)
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &
# Run docker
# Pass it all the command line args ($@)
# set the network to "host" so docker can talk to localhost
docker $@ --network='host'

Di Dockerfile kami terhubung melalui localhost ke host ssh-agent:

FROM python:3-stretch

COPY . /app
WORKDIR /app

RUN mkdir -p /tmp

# install socat and ssh to talk to the host ssh-agent
RUN  apt-get update && apt-get install git socat openssh-client \
  # create variable called SSH_AUTH_SOCK, ssh will use this automatically
  && export SSH_AUTH_SOCK=/tmp/auth.sock \
  # make SSH_AUTH_SOCK useful by connecting it to hosts ssh-agent over localhost:56789
  && /bin/sh -c "socat UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:localhost:56789 &" \
  # stuff I needed my ssh keys for
  && mkdir -p ~/.ssh \
  && ssh-keyscan gitlab.com > ~/.ssh/known_hosts \
  && pip install -r requirements.txt

Kemudian Anda dapat membangun gambar Anda dengan menjalankan skrip:

$ docker_with_host_ssh.sh build -f ../docker/Dockerfile .

@cowlicks Anda mungkin tertarik dengan permintaan tarik ini, yang menambahkan dukungan untuk docker build --ssh untuk meneruskan agen SSH selama pembuatan; https://github.com/docker/cli/pull/1419. Sintaks Dockerfile masih belum ada dalam spesifikasi resmi, tetapi Anda dapat menggunakan direktif syntax=.. di Dockerfile Anda untuk menggunakan frontend yang mendukungnya (lihat contoh/petunjuk dalam permintaan tarik).

Permintaan tarik itu akan menjadi bagian dari rilis 18.09 mendatang.

Sepertinya ini sekarang tersedia dalam rilis 18.09. Karena utas ini muncul sebelum catatan rilis dan posting menengah, saya akan memposting silang di sini.

Catatan Rilis:
https://docs.docker.com/develop/develop-images/build_enhancements/#using -ssh-to-access-private-data-in-builds

Pos Sedang:
https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

Sangat seru.

@kalenp lihat juga https://github.com/moby/buildkit/issues/760 dan https://github.com/moby/buildkit/issues/825

Saya pikir kita bisa menutup ini karena kita punya docker build --ssh sekarang

Masalah penulisan terkait di sini: docker/compose#6865. Fungsionalitas untuk menggunakan Compose dan mengekspos soket agen SSH ke container yang tercatat akan mendarat di kandidat rilis berikutnya, 1.25.0-rc3 ( rilis ).