ping @ewindisch @diogomonica @NathanMcCauley Ini hanya tulisan singkat. Jangan ragu untuk mengubah/memperbarui deskripsi jika menurut Anda perlu :)

Ini adalah info yang berguna:

https://github.com/hashicorp/vault/issues/165

Seperti ini:

https://github.com/hashicorp/vault/issues/164

@ dreamcat4 ada beberapa rencana untuk mengimplementasikan "API rahasia" generik, yang memungkinkan Anda menggunakan Vault, atau Keywiz atau beri nama dengan Docker, tetapi semuanya dengan cara yang sama. Itu baru pemikiran awal, sehingga akan membutuhkan penelitian tambahan.

@thaJeztah Ya, Maaf, saya tidak ingin mengurangi upaya / diskusi itu dengan cara apa pun. Saya lebih berpikir mungkin ini adalah latihan yang berguna juga (sebagai bagian dari proses yang lebih panjang dan sementara kita menunggu) untuk melihat seberapa jauh kita bisa mencapai sekarang. Kemudian menunjukkan lebih jelas kepada orang lain batasan dan kekurangan dalam proses saat ini. Apa yang mendasarinya hilang dan paling perlu ditambahkan untuk meningkatkan rahasia.

Juga perlu dipertimbangkan tentang situasi yang berbeda dari rahasia run-time VS rahasia waktu pembuatan. Untuk itu ada juga area yang tumpang tindih.

Dan mungkin juga (untuk buruh pelabuhan) kita mungkin juga layak untuk mempertimbangkan batasan (pro/kontra) antara solusi yang menyediakan mekanisme untuk menangani rahasia "dalam memori". Berbeda dengan metode rahasia berbasis file yang lebih berat atau yang berbasis jaringan, misalnya server rahasia lokal. Yang merupakan peretasan saat ini di atas meja (sampai API rahasia yang tepat). Ini dapat membantu kami untuk memahami beberapa nilai unik (misalnya keamanan yang lebih kuat) yang ditambahkan oleh API rahasia buruh pelabuhan yang tidak dapat dicapai dengan menggunakan peretasan di atas kumpulan fitur buruh pelabuhan saat ini. Namun saya bukan ahli keamanan. Jadi saya tidak bisa mengomentari hal-hal itu dengan sangat pasti.

@dreamcat4 ya, Anda benar; untuk jangka pendek, link tersebut memang bermanfaat.

Juga perlu dipertimbangkan tentang situasi yang berbeda dari rahasia run-time VS rahasia waktu pembuatan. Untuk itu ada juga area yang tumpang tindih.

Terima kasih! Saya pikir saya memilikinya dalam deskripsi asli saya, pasti tersesat dalam prosesnya. Saya akan menambahkan peluru

Namun saya bukan ahli keamanan.

Saya juga tidak, itu sebabnya saya "ping" penjaga keamanan; IMO, ini seharusnya sesuatu yang ditulis oleh mereka

@thaJeztah ringkasan yang bagus. Saya akan mencoba menyodok ini setiap kali saya menemukan waktu.

@diogomonica meskipun tidak _directly_ terkait, ada permintaan fitur lama terbuka untuk meneruskan agen kunci SSH selama membangun; https://github.com/docker/docker/issues/6396 mengingat jumlah komentar, akan lebih baik untuk memikirkannya juga. (Bahkan jika untuk mengambil keputusan tentang apakah itu dapat/harus dilaksanakan atau tidak)

Dengan asumsi Anda dapat memasang volume sebagai pengguna selain root (saya tahu itu tidak mungkin, tetapi menghibur saya), apakah itu pendekatan yang menguntungkan untuk memasukkan rahasia ke dalam wadah?

Jika demikian, saya akan menganjurkan alternatif untuk -v host_dir:image_dir yang mengharapkan penggunaan wadah khusus data dan mungkin terlihat seperti -vc host_dir:image_dir (mis. volume-copy) di mana konten Host_dir berada disalin ke volume image_dir pada wadah khusus data.

Kami kemudian dapat menekankan paradigma secure-data-only containers dan mengizinkan volume tersebut untuk dienkripsi

Saya baru-baru ini membaca artikel bagus tentang itu dari @jrslv di mana ia mengusulkan untuk membangun gambar buruh pelabuhan khusus dengan rahasia hanya untuk membangun aplikasi Anda, dan daripada membangun gambar lain untuk distribusi menggunakan hasil dari menjalankan gambar build.

Jadi, Anda memiliki dua file Docker:

• Dockerfile.build (di sini Anda cukup menyalin semua rahasia Anda)
• Dockerfile.dist (yang ini Anda akan mendorong ke registri)

Sekarang kita dapat membangun distribusi kita seperti itu:

# !/bin/sh
docker build -t hello-world-build -f Dockerfile.build .
docker run hello-world-build >build.tar.gz 
docker build -t hello-world -f Dockerfile.dist ^

Rahasia Anda aman, karena Anda tidak pernah mendorong gambar hello-world-build .

Saya sarankan untuk membaca artikel @jrslv untuk detail lebih lanjut http://resources.codeship.com/ebooks/continuous-integration-continuous-delivery-with-docker

Terima kasih telah berbagi @kepkin !
Baru selesai baca artikelnya. Benar-benar ringkas!

Saya suka ide mengekspor file dan memuatnya melalui Dockerfile terpisah. Rasanya seperti terjepit tanpa masalah "lapisan perantara berada di cache build".

Namun, saya khawatir itu akan memperumit pengembangan dan mungkin memerlukan Dockerfile ketiga untuk kesederhanaan.

@kepkin jangan tersinggung tapi itu tidak masuk akal. Rahasia jelas tidak aman, karena ada di dalam tarball dan tarball sedang ADD diedit ke gambar produksi -- bahkan jika Anda menghapus tarball, tanpa tergencet, itu akan bocor di beberapa lapisan.

@TomasTomecek jika saya memahami contoh dengan benar, tarball adalah _bukan_ lapisan gambar, tetapi hanya biner yang dibangun di dalam wadah build. Lihat misalnya; https://github.com/docker-library/hello-world/blob/master/update.sh (tidak ada rahasia yang terlibat di sini, tetapi hanya contoh sederhana dari wadah build)

@TomasTomecek Saya sedang berbicara tentang rahasia untuk membangun citra Docker. Misalnya, Anda harus meneruskan kunci ssh ke checkout kode sumber dari repositori GitHub pribadi Anda. Dan tarball hanya berisi artefak build tetapi tidak berisi kunci GitHub.

@kepkin benar, sekarang saya membaca posting Anda lagi dan dapat melihatnya. Maaf tentang itu. Sayangnya itu tidak menyelesaikan masalah ketika Anda membutuhkan rahasia selama penyebaran/membangun gambar distribusi (misalnya mengambil artefak dan mengautentikasi dengan layanan artefak). Tapi itu jelas merupakan solusi yang baik untuk pemisahan antara proses build dan proses rilis.

@TomasTomecek itulah cara saya mengambil artefak sebenarnya.

Dalam gambar Docker.build saya mengunduh beberapa dependensi biner dari gambar Amazon S3 yang memerlukan kunci & rahasia AWS. Setelah mengambil dan membangun, saya membuat tarball dengan semua yang saya butuhkan.

Apakah ada artikel "praktik terbaik" kanonik -- "Lakukan" seperti yang diinformasikan pada "Larangan" -- yang akan Anda rekomendasikan untuk dibaca?

Perlu dicatat (untuk orang lain seperti saya yang menemukan ini) bahwa Docker Compose memiliki dukungan untuk opsi env_file .

https://docs.docker.com/compose/compose-file/#env -file

@afeld docker sendiri memiliki fitur ini juga, lihat http://docs.docker.com/engine/reference/commandline/run/#set -environment-variables-e-env-env-file tetapi env-vars itu masih akan muncul di tempat yang sama, jadi jangan membuat perbedaan dengan "bocor"

Saya menemukan lembar contekan ini: http://container-solutions.com/content/uploads/2015/06/15.06.15_DockerCheatSheet_A2.pdf

@kepkin ini adalah bagaimana saya meneruskan kunci ssh ke docker build :

# serve the ssh private key once over http on a private port.
which ncat
if [ "$?" = "0" ]; then
  ncat -lp 8000 < $HOME/.ssh/id_rsa &
else
  nc -lp 8000 < $HOME/.ssh/id_rsa &
fi
nc_pid=$!
docker build --no-cache -t bob/app .
kill $nc_pid || true

dan di dalam Dockerfile di mana 172.17.0.1 adalah IP gateway buruh pelabuhan:

RUN \
  mkdir -p /root/.ssh && \
  curl -s http://172.17.0.1:8000 > /root/.ssh/id_rsa && \
  chmod 600 /root/.ssh/id_rsa && chmod 700 /root/.ssh && \
  ssh-keyscan -t rsa,dsa github.com > ~/.ssh/known_hosts && \
  git clone --depth 1 --single-branch --branch prod [email protected]/app.git . && \
  npm i --production && \
  ... && \
  rm -rf /root/.npm /root/.node-gyp /root/.ssh

Jika seseorang memiliki sesuatu yang lebih sederhana, beri tahu kami.

Jadi apa status saat ini?

Sepanjang musim panas ada rantai percakapan yang panjang, menunjukkan betapa meluasnya kekhawatiran ini. Ini diajukan pada bulan Mei, dan masih terbuka. Misalnya, bagaimana saya mengatur kata sandi untuk Postgres?

@thaJeztah Apa yang bisa dilakukan untuk memajukan ini? Saya kira banyak mata di seluruh proyek hilir yang berbeda tertuju pada masalah ini... ej. https://github.com/rancher/rancher/issues/1269

Saya kira apa yang sedang dilakukan di sini dirahasiakan _ :D

Ini titik kesulitan terbesar bagi kami untuk mengintegrasikan Docker ke dalam tumpukan produksi kami. Apakah ada peta jalan atau dokumen lain di suatu tempat yang menunjukkan kemajuan ke arah ini?

Beberapa konten yang relevan tentang topik ini dari k8s .

Apa pendapat Anda tentang ini sebagai cara potensial untuk mengatasi rahasia run-time?
https://github.com/docker/docker/issues/19508

Saya merasa masalah ini akan lebih baik ditangani dengan berkonsentrasi pada beberapa skenario yang perlu didukung, dan memastikan ada serangkaian instruksi untuk masing-masing skenario. Bagaimana penerapannya kurang penting daripada apakah di akhir proses ada serangkaian fitur yang koheren yang dapat digabungkan untuk memenuhi kebutuhan.

Beberapa yang saya lihat dirujuk yang tampaknya merupakan masalah yang cukup sah meliputi:

Kredensial Run-time

• Informasi pengguna/sandi terkoordinasi antara dua wadah yang berbagi link
• Informasi mudah disimpan dari repositori git Anda
• Informasi mudah disimpan dari gambar yang Anda dorong (bagaimana dengan wadah lokal?)
• Informasi mudah dijauhkan dari .bash_history (mungkin jembatan terlalu jauh?)
• Beberapa aplikasi mengharapkan rahasia sebagai bagian dari file konfigurasi yang berisi informasi lain
• Beberapa aplikasi mengharapkan rahasia sebagai variabel lingkungan
• Beberapa aplikasi memungkinkan keduanya

Ketika saya mengatakan 'mudah' yang saya maksud adalah bahwa ada pendekatan ergonomis yang waras untuk menangani variabel-variabel ini yang melindungi pengguna dari kesalahan yang tidak disengaja dan memicu buletin keamanan. Tekanan pengalaman sering dikaitkan dengan (baca: disalahkan) alat yang terlibat dalam kesalahan.

Kredensial waktu pembuatan

• Proyek dibangun dari satu atau lebih repositori pribadi (mis: package.json memungkinkan url git)
• Builder mungkin berada di belakang proxy yang dilindungi kata sandi
• Builder mungkin menggunakan cache yang dilindungi kata sandi
• Pengguna akhir hanya peduli dengan gambar yang berfungsi (yaitu, mereka akan menggunakan pull atau FROM, tidak pernah docker build )
• Informasi mudah dijauhkan dari gambar yang Anda dorong

Sunting ke-1:

Dokumentasi apa yang ada dan tidak 'bocor' menjadi gambar yang khas, wadah

• File apa yang muncul di gambar (Hanya COPY dan ADD? apa lagi?)
• Mesin buruh pelabuhan apa yang dipertahankan setelah gambar dibuat (terutama boot2docker, tetapi bagaimana dengan yang lain?)
• Bagaimana variabel lingkungan dan baris perintah ditangkap dalam gambar, dan di mana mereka ditangkap
• Harapan pada penerbit PR tentang perubahan perilaku ini

Saya merasa seperti saya kehilangan beberapa yang besar di sini. Adakah yang punya sesuatu yang saya lupa?

Kunci API untuk layanan json apa pun.

Misalnya (dan ini adalah kasus penggunaan saya yang sebenarnya), build Docker mengkompilasi sebuah program, Kunci API diperlukan untuk mengautentikasi saya dan mengunggah produk build ke Bintray.com.

@ dreamcat4 Saya mungkin jauh dari apa yang Anda katakan, tetapi begini:

Apakah Anda berbicara tentang menggunakan gambar buruh pelabuhan untuk build Continuous Deployment, dan mendorong artefak build ke arsip di akhir build yang berhasil? Secara pribadi saya lebih suka melakukan ini lebih jauh ke hulu (misalnya, skrip pasca-pembuatan di Jenkins), tetapi jika Anda melakukan kompilasi silang, itu mungkin sedikit lebih rumit.

Di dunia saya, agen build hanya membuat binari/arsip dan menyimpannya sebagai 'artefak' dari proses pembuatan, dan sesuatu yang lain mendorongnya ke infrastruktur, menandai repositori git, dll. Itu memberi saya cadangan darurat artefak jika saya memiliki masalah produksi dan, katakanlah, repositori npm, docker, atau Artifactory saya tidak aktif untuk peningkatan, atau jaringan saya bermasalah.

Poin yang saya coba sampaikan adalah tentang penggunaan kunci API secara umum. Ada banyak layanan JSON/istirahat online yang berbeda dan bervariasi yang mungkin perlu berinteraksi dengan wadah (baik pada waktu pembuatan atau waktu berjalan)... yang memerlukan kunci API. Tidak harus secara khusus tentang membangun terkait.

@dreamcat oh, jadi token

Ya, saya pikir kedua jenis itu harus dipertimbangkan secara berbeda dalam hal mengevaluasi tingkat keamanan minimum dasar mereka.

Token API Auth cenderung sering:

• Bukan kata sandi
• Bisa dicabut
• Beberapa (subset yang jauh lebih sedikit) adalah sekali pakai - buang. Dan pada dasarnya membatalkan diri mereka sendiri.
• Seringkali layanan API terbatas dalam cakupannya hanya pada sebagian fungsi. (yaitu hanya-baca, atau hanya dapat memicu tindakan tertentu).

Kata sandi cenderung / sering:

• Untuk akses/kontrol akun yang lebih lengkap.
• Setelah dikompromikan, dapat diubah oleh penyerang ke sesuatu yang lain (lock out). Atau backdoor lain yang dimasukkan (seperti modifikasi db dari akun lain yang disimpan di database, dalam kasus SQL).
• Menjadi kata sandi membuat risiko 'penggunaan kembali kata sandi yang sama' jauh lebih tinggi di antara akun lain. Sementara kunci API cenderung selalu unik dan tidak dapat digunakan untuk hal lain.

Jadi bukan berarti solusi rahasia _harus berbeda_ untuk 2 tipe tersebut. Hanya saja, tingkat keamanan dasar minimum yang dapat diterima mungkin sedikit lebih rendah untuk kunci API.

Level minimum ini penting jika memiliki keamanan yang kuat lebih kompleks / bermasalah untuk disetel. (yang mungkin benar di sini dalam hal rahasia buruh pelabuhan, atau tidak tergantung seberapa layak/elegan solusinya).

Dan terkadang kunci API kata sandi dapat memiliki keamanan yang lebih kuat/lemah. Hanya saja jika satu ukuran untuk semua tidak mungkin.

Misalnya - kunci API bintray saya: yang disimpan di repo .git yang sama dengan Dockerfile saya. Jadi untuk menjaganya tetap aman disimpan di PRIVATE git repo (diakses melalui SSH). Jadi mendapatkan akses ke kunci API relatif terlindungi dengan baik di sana. Namun tanpa buruh pelabuhan yang memiliki fungsionalitas / perlindungan rahasia bawaannya sendiri, gambar buruh pelabuhan yang dibangun selalu menyertakan kunci API dalam teks biasa. Oleh karena itu, gambar build Docker yang dihasilkan harus dirahasiakan seperti repositori git... yang memiliki efek knock-on (efek yang tidak diinginkan) sehingga tidak ada orang lain yang dapat melihat/melihat log build/status build di sana secara publik.

Sekarang itu tidak ideal dalam banyak hal. Tetapi solusi keseluruhannya cukup sederhana dan benar-benar berfungsi (seperti pada: kemarin). Jika ada mekanisme yang lebih baik yang dibuat di masa depan, saya akan mempertimbangkan untuk beralih ke mekanisme itu. Tetapi tidak jika mekanisme itu secara signifikan lebih mahal / rumit untuk disiapkan daripada solusi saat ini yang telah saya buat. Jadi karena itu keamanan ekstra kuat (walaupun diterima) mungkin berlebihan jika hanya 1 kunci api. Yang hanya perlu dijauhkan dari cache lapisan gambar buruh pelabuhan dengan semacam opsi NOCAHCE / perintah Dockerfile baru.

Sementara kata sandi membutuhkan sesuatu seperti vault atau ansible-vault, dan untuk dienkripsi dengan kata sandi lain atau mekanisme otentikasi yang sangat aman lainnya. (Yang kami harap tidak tetapi mungkin merupakan hal yang rumit untuk disiapkan).

Saya pikir model klien/server (seperti di vault ) untuk mengelola dan merampingkan (baca: mengaudit, memecahkan kaca) semua rahasia yang terkait dengan hal-hal akan menjadi praktik yang baik dan akan mencakup sebagian besar kasus penggunaan, jika implementasi dilakukan dengan serius. Saya, secara pribadi, bukan penggemar mengadopsi pendekatan non-holistik, karena ini adalah kesempatan untuk meningkatkan standar dalam praktik terbaik.

Ini menyiratkan klien yang berjalan lama (tanggung jawab orang yang menyebarkan gambar) dan/atau klien waktu pembangunan (tanggung jawab pembuat). Mungkin yang pertama dapat ditransfer ke daemon buruh pelabuhan entah bagaimana yang memberikan rahasia resmi saat dijalankan.

Memang - saya sepenuh hati setuju dengan komentar sebelumnya. Bukannya saya tidak mengagumi cara kreatif di mana orang memecahkan masalah, tapi saya rasa ini tidak perlu - mari kita coba dan pikirkan solusi yang dapat digunakan baik selama CI/D dan runtime , serta mempertimbangkan bahwa container mungkin diatur oleh Mesos/Kubernetes, dll.

Yah, saya pikir sedikit dokumentasi masih akan berguna di sini, karena Docker menyajikan beberapa kekusutan tambahan di ruang masalah.

Sepertinya orang-orang Vault juga melihat ini dari sisi mereka. Saya pikir tiket ini adalah yang harus ditonton:

https://github.com/hashicorp/vault/issues/165

Mungkin ini yang bisa dikerjasamakan.

@jdmarshall

Mungkin ini yang bisa dikerjasamakan.

+1

+1 Docker + Hashi Corp Vault

Maaf, tapi saya tidak suka bagaimana solusinya menjadi lebih kompleks karena semakin banyak orang yang terlibat. Hashi Corp Vault misalnya adalah solusi server klien lengkap dengan penyimpanan ujung belakang terenkripsi. Itu menambahkan lebih banyak bagian yang bergerak. Saya yakin beberapa kasus penggunaan menuntut tingkat kerumitan ini, tetapi saya ragu sebagian besar akan melakukannya. Jika solusi yang bersaing adalah menggunakan variabel lingkungan Host, saya cukup yakin yang pada akhirnya akan digunakan oleh sebagian besar pengembang.

Saya sedang mencari solusi yang mencakup pengembangan (mis: kunci github) dan penerapan (mis: kunci sertifikat nginx, kredensial db). Saya tidak ingin mencemari Host dengan env vars atau membangun alat dan tentu saja tidak ada rahasia yang berakhir di github (tidak terenkripsi) atau direktori gambar buruh pelabuhan, bahkan yang pribadi.

@gittycat Saya setuju dengan Anda dalam arti bahwa mungkin ada beberapa kasus penggunaan yang berbeda. Dimana beberapa solusi harus lebih sederhana daripada yang lain.

Kami tentu saja ingin menghindari beralih ke ENV vars sekalipun.

Preferensi saya sendiri condong ke gagasan bahwa penyimpanan kunci sederhana dapat dicapai dengan sesuatu yang mirip dengan mekanisme "kubah" yang memungkinkan. Di mana Anda memiliki file teks terenkripsi yang disimpan dalam konteks build (atau sumber di luar / di samping konteks build). Kemudian kunci pembuka kunci dapat membuka kunci kata sandi teks biasa atau kunci API dll dari file itu.

Saya hanya mengatakan itu setelah menggunakan solusi "kubah" yang ada. Yang relatif tidak menyakitkan / sederhana. Lemari besi Hashicorp lebih aman, tetapi juga lebih sulit untuk diatur dan umumnya lebih kompleks. Meskipun saya tidak tahu alasan teknis mengapa Anda pada akhirnya tidak dapat menggunakannya di bawahnya sebagai backend (sembunyikan/sederhanakan di belakang alat commandline berorientasi buruh pelabuhan).

Saya akan menyarankan penyimpanan file lokal karena menghindari perlunya menyiapkan beberapa server penyimpanan kunci HTTP yang kompleks dan berpotensi tidak dapat diandalkan. Penyimpanan rahasia sangat merupakan masalah keamanan sehingga harus tersedia untuk semua pengguna, tidak hanya untuk perusahaan. Hanya 2 sen pendapat saya.

+1 ke backend penyimpanan file lokal, untuk kasus penggunaan yang lebih lanjut, namun saya lebih suka kekuatan penuh dari solusi seperti Hashicorp Vault. Ketika kita berbicara tentang penyebaran, dalam sebuah organisasi, argumennya adalah, bahwa orang-orang yang memberikan dan mengendalikan rahasia adalah orang lain daripada mereka yang menggunakannya. Ini adalah tindakan keamanan umum untuk menjaga lingkaran orang-orang dengan kekuatan pengendali terbatas pada insinyur keamanan yang sangat tepercaya...

Tidak tahu apakah ini berguna atau akan berhasil, tetapi inilah sedikit saran bidang kiri untuk menyelesaikan kasus di mana saya ingin menyuntikkan rahasia ke dalam wadah saat runtime (misalnya kata sandi postgres)

Jika saya dapat mengganti pada docker run waktu titik masuk dan mengaturnya ke skrip yang saya pilih misalnya /sbin/get_secrets, yang setelah mendapatkan rahasia dari mekanisme yang saya pilih (misalnya KMS), itu akan mengeksekusi titik masuk asli (sehingga menjadi pembungkus belaka yang tujuan utamanya adalah untuk mengatur variabel lingkungan dengan rahasia di dalamnya DI DALAM wadah. Skrip semacam itu dapat diberikan saat runtime melalui pemasangan volume. Mekanisme seperti itu tidak akan melibatkan rahasia yang pernah ditulis ke disk ( salah satu hewan peliharaan saya benci), atau dibocorkan oleh buruh pelabuhan (bukan bagian dari pemeriksaan buruh pelabuhan), tetapi akan memastikan mereka hanya ada di dalam lingkungan proses 1 di dalam wadah, yang menjaga 12-factorness.

Anda sudah dapat melakukan ini (saya percaya) jika titik masuk tidak digunakan dalam metadata gambar, tetapi hanya cmd, karena titik masuk kemudian membungkus perintah. Seperti yang disebutkan, pembungkus kemudian dapat dipasang saat runtime melalui volmount. Jika titik masuk sudah digunakan dalam metadata gambar, maka saya pikir Anda tidak dapat melakukannya saat ini kecuali jika mungkin untuk melihat titik masuk asli dari dalam wadah (bukan penggantian cmdline) - tidak yakin apakah Anda dapat melakukannya atau tidak .

Akhirnya saya pikir bahkan mungkin untuk menyediakan kunci satu kali terenkripsi melalui injeksi env var tradisional yang dapat digunakan oleh /sbin/get_secrets eksternal untuk meminta rahasia yang sebenarnya (misalnya kata sandi postgres), sehingga menambahkan perlindungan ekstra ke buruh pelabuhan membocorkan kunci satu kali.

Saya tidak tahu apakah ini hanya lapisan demi lapisan, atau apakah itu berpotensi menyelesaikan masalah .. maaf jika hanya yang pertama.

@thaJeztah - Saya dapat mengonfirmasi solusi yang saya

@gtmtech Menarik. Akan tertarik pada bagaimana Anda menemukan titik masuk asli dari get secret binary Anda..

Mungkin folder kode contoh akan membuat pendekatan ini sedikit lebih mudah untuk ditunjukkan/dipahami.

Contoh kode dan skenario kerja di sini @dreamcat4 @kaos >

https://github.com/gtmtechltd/secret-squirrel

Saya mungkin salah, tetapi mengapa metode rumit ini? Saya mengandalkan izin file unix standar. Serahkan semua rahasia ke buruh pelabuhan dengan -v /etc/secrets/docker1:/etc/secrets hanya dapat dibaca oleh root dan kemudian ada skrip yang berjalan pada startup wadah sebagai root, yang meneruskan rahasia ke tempat yang sesuai untuk program yang relevan (misalnya konfigurasi Apache). Program-program ini menjatuhkan izin root saat startup sehingga jika diretas, mereka tidak dapat membaca rahasia yang dimiliki root nanti. Apakah metode yang saya gunakan ini salah?

Terima kasih @gtmtech :)
Sayangnya, kami tidak memiliki titik masuk standar, saya juga tidak dapat menjalankan pemeriksaan buruh pelabuhan sebelum buruh pelabuhan berjalan secara terkendali.. Tapi saya menyukai pendekatan Anda.

Saya mungkin salah, tetapi mengapa metode rumit ini? Saya mengandalkan izin file unix standar. Serahkan semua rahasia ke buruh pelabuhan dengan -v /etc/secrets/docker1:/etc/secrets hanya dapat dibaca oleh root dan kemudian ada skrip yang berjalan pada startup wadah sebagai root, yang meneruskan rahasia ke tempat yang sesuai untuk program yang relevan (misalnya Apache konfigurasi). Program-program ini menjatuhkan izin root saat startup sehingga jika diretas, mereka tidak dapat membaca rahasia yang dimiliki root nanti. Apakah metode yang saya gunakan ini salah?

Hai,
Saya setuju dan berpikir pendekatan ini ^^ secara umum harus direkomendasikan sebagai cara terbaik untuk rahasia RUNTIME. Kecuali orang lain di sini memiliki keberatan yang kuat terhadap itu. Setelah itu kemudian dapat juga membuat daftar kasus sudut yang tersisa (pada RUNTIME) yang tidak tercakup oleh itu ^^.

Sayangnya saya tidak bisa melihat rahasia tupai lepas landas karena terlalu rumit untuk kebanyakan orang non-teknis biasa untuk belajar dan mengadopsi sebagai beberapa strategi populer.

Jadi itu pergi (Anda mungkin sudah menebaknya) ...
Rahasia waktu pembuatan!

Tapi saya pikir itu kemajuan! Karena setelah waktu yang lama tidak benar-benar mendapatkan apa-apa, mungkin memotong setengah dan menyelesaikan kira-kira 45-50% dari total masalah.

Dan jika masih ada masalah seputar rahasia, setidaknya akan lebih spesifik / terfokus dan dapat terus berkembang / takle setelahnya.

Ya, saya tidak akan membahas terlalu banyak detail, tetapi pendekatan ini tidak akan pernah berhasil untuk situasi yang sedang saya tangani, karena saya membutuhkan tingkat keamanan yang lebih tinggi daripada yang mereka berikan. Misalnya, tidak ada rahasia yang tidak dienkripsi pada disk, tidak ada kunci dekripsi yang valid setelah didekripsi dalam proses target, rotasi enkripsi reguler, dan repositori tunggal untuk rahasia terenkripsi (dan tidak tersebar di seluruh server). Jadi lebih untuk orang-orang yang harus melakukan tingkat keamanan yang saya sarankan pendekatan yang mungkin.

secret_squirrel bagaimanapun juga merupakan peretasan di ruang di mana saya belum dapat melihat solusi yang layak, di sekitar buruh pelabuhan yang belum menyediakan api rahasia, atau driver rahasia yang dapat dicolokkan, yang mudah-mudahan mereka akan melakukannya di beberapa titik, tetapi mungkin ini berfungsi untuk menggambarkan pengaturan ENV itu vars di dalam wadah sebelum proses exec, tetapi bukan sebagai bagian dari proses pembuatan buruh pelabuhan (atau metadata) adalah cara aman untuk mematuhi 12-faktor dengan rahasia, dan mungkin komunitas pengembang buruh pelabuhan dapat menggunakan ide itu ketika mereka mulai membangun sebuah rahasia-api/driver jika mereka pikir itu bagus!

Selamat berlabuh!

Kami telah menggunakan jenis pendekatan yang dijelaskan oleh @gtmtech , dengan sangat sukses. Kami menyuntikkan rahasia terenkripsi KMS melalui variabel lingkungan, lalu membiarkan kode di dalam wadah didekripsi sesuai kebutuhan.

Biasanya itu melibatkan titik masuk shim sederhana, di depan aplikasi. Kami saat ini menerapkan shim itu dengan kombinasi shell dan biner Golang kecil (https://github.com/realestate-com-au/shush), tapi saya suka suara pendekatan pure-Go.

@gtmtech @mdub Saya pasti akan senang melihat lebih banyak dari ini.
@ dreamcat4 Saya pikir definisi "rumit" mungkin bergantung pada jalur, yang jelas cukup ok. Namun, itu mungkin tidak bisa menjadi penilaian yang abstrak. Oleh karena itu, bagaimanapun, pembungkus keamanan di dalam wadah buruh pelabuhan tampaknya bukan sesuatu yang terlalu rumit bagi saya di tingkat desain. Aspek lain adalah praktik terbaik: Itu perlu dilihat bukan dari perspektif pengembang saja, tetapi dari perspektif operasi.
2 sen saya

Gudang +1

Gudang -1. Vault memiliki beberapa karakteristik operasional (unsealing) yang membuatnya sangat tidak diinginkan bagi banyak orang.

Memiliki API yang dapat dipasang adalah yang paling masuk akal.

Ada juga brankas yang memungkinkan. Itu adalah binatang yang agak berbeda.

@gtmtech terima kasih atas sarannya, itu mengilhami saya untuk menulis titik masuk ini:

#!/bin/bash

if [ -d "/var/secrets" ]; then
  tmpfile="$(mktemp)"
  for file in /var/secrets/*
  do
    if [ -f $file ]; then
      file_contents=$(cat $file)
      filename=$(basename "$file")
      underscored_filename="${filename//-/_}"
      capitalized_filename=${underscored_filename^^}
      echo "export $capitalized_filename=$file_contents" >> $tmpfile
    fi
  done

  source $tmpfile
  rm -f $tmpfile
fi

exec "$@"

Saya hanya menambahkannya ke Dockerfile seperti ini (jangan lupa chmod + x di atasnya):

ENTRYPOINT ["/app/docker-entrypoint.sh"]

Dan voila. ENV vars tersedia saat runtime. Cukup baik :)

Jika saya mengerti dengan benar, dir /var/secrets harus di-mount melalui volume kan??
Juga, ketika ada komentar tentang rahasia yang tidak ditulis ke disk, seberapa buruk menulisnya ke disk dan kemudian menghapusnya???

Bagus! Anda harus menggunakan shred untuk menghapus file dengan aman.

Pada hari Kamis, 3 Maret 2016, Juan Ignacio Donoso [email protected]
menulis:

Jika saya mengerti dengan benar, direktori /var/secrets harus dipasang melalui
volume kan??
Juga, ketika ada komentar tentang rahasia yang tidak ditulis ke disk, bagaimana
buruk adalah menulisnya ke disk dan kemudian menghapusnya???

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

Rui Marinho

Terinspirasi oleh "tupai rahasia" @gtmtech , saya telah memperluas alat manajemen rahasia saya "shush" untuk membuatnya dapat digunakan sebagai titik masuk gambar:

ADD shush_linux_amd64 /usr/local/bin/shush
ENTRYPOINT ["/usr/local/bin/shush", "exec", "--"]

Ini mendekripsi semua variabel KMS_ENCRYPTED_xxx , dan memasukkan hasilnya kembali ke lingkungan.

https://github.com/realestate-com-au/shush#use -as-a-command-shim

Jadi utas dimulai dengan JANGAN LAKUKAN HAL INI .....

... tapi saya tidak melihat TOLONG LAKUKAN HAL INI BUKAN ... hanya berbagai proposal/peretasan yang sebagian besar ditolak/ditutup.

Apa praktik terbaik resmi untuk saat ini? Sebagai pengguna buruh pelabuhan, agak frustasi melihat daftar panjang hal-hal yang tidak boleh kita lakukan tetapi kemudian tidak ada alternatif resmi yang ditawarkan. Apakah saya melewatkan sesuatu? Apakah satu tidak ada? Saya yakin banyak hal terjadi di belakang layar dan ini adalah sesuatu yang sedang dikerjakan oleh tim buruh pelabuhan, tetapi untuk saat ini, bagaimana cara terbaik kita menangani manajemen rahasia sampai solusi kanonik disajikan?

@alexkolson
Sejauh yang saya pahami, jika Anda memerlukan rahasia saat runtime, Anda harus menggunakan volume (rahasia sistem file) atau beberapa layanan seperti HashiCorp Vault (rahasia jaringan).

Untuk rahasia waktu pembuatan, ini lebih rumit.
Volume tidak didukung pada waktu pembuatan, jadi Anda harus menggunakan wadah untuk menjalankan perintah yang memodifikasi sistem file, dan menggunakan komit buruh pelabuhan.

Jadi yang hilang adalah kemampuan untuk mengelola rahasia pada waktu pembuatan menggunakan apa pun kecuali file Docker, tanpa perlu menggunakan docker commit .

Beberapa orang bahkan mengatakan bahwa menggunakan sistem file untuk rahasia tidak aman, dan daemon buruh pelabuhan itu harus menyediakan beberapa API untuk menyediakan rahasia dengan aman (menggunakan jaringan/firewall/volume otomatis?). Tetapi tidak ada yang tahu seperti apa tampilan API ini dan bagaimana orang akan menggunakannya.

Ketika saya memikirkan kedatangan singkat env vars, saya memikirkan masalah khusus non-docker seperti:

1. Menggabungkan log yang menangkap semua env vars atau phpinfo yang terlupakan yang tertinggal di server web produksi - jadi berhati-hatilah dengan rahasia dan konfigurasikan dengan benar.
2. Mungkin trojan yang mengekspos env vars - jadi jangan jalankan perangkat lunak yang tidak tepercaya.
3. Serangan yang mengeksploitasi kelemahan seperti injeksi sql - jadi validasi input dan gunakan firewall aplikasi web.

Kelemahan yang disajikan di bagian atas utas ini:

Dapat diakses oleh proses apa pun dalam wadah, sehingga mudah "bocor"

Cross apply 1 & 2 dari atas. Sah tapi disikapi dengan hati-hati kan? Plus, wadah buruh pelabuhan Anda menjalankan proses yang jauh lebih sedikit daripada server web tumpukan penuh.

Bagaimana dengan konfigurasi di env var, tetapi env vars rahasia memiliki nilai terenkripsi dan aplikasi memiliki kunci dalam kode? Ini hanya kebingungan, karena kuncinya ada dalam kode, tetapi akan membutuhkan eksploitasi untuk mendapatkan akses ke kunci dan env vars. Mungkin menggunakan manajemen konfigurasi untuk mengelola kunci di host buruh pelabuhan daripada di kode aplikasi. Dapat membantu proses rouge dan kebocoran yang tidak disengaja tetapi jelas bukan serangan injeksi dari seseorang yang memiliki kuncinya.

Diawetkan di lapisan tengah gambar, dan terlihat di inspeksi buruh pelabuhan

Apakah orang-orang memanggang env vars ke gambar buruh pelabuhan daripada mengatur saat run time atau apakah saya salah paham dengan yang ini. Jangan pernah mengembalikan rahasia menjadi artefak bukan? Ya sudo docker inspect container_name memberikan env var, tetapi jika Anda di server produksi saya maka iv sudah hilang. sudo docker inspect image_name tidak memiliki akses vars env saya yang disetel saat run time.

Dibagikan dengan wadah apa pun yang ditautkan ke wadah

Bagaimana kalau tidak menggunakan link dan jaringan baru saja?

Satu-satunya masalah yang tampak seperti masalah buruh pelabuhan dan tidak universal adalah tautan ...

Tempatkan saya di kelompok orang yang membutuhkan cara yang baik untuk menangani rahasia selama docker build . Kami menggunakan komposer untuk beberapa proyek php dan mereferensikan beberapa repo github pribadi untuk dependensi. Ini berarti jika kita ingin membangun segala sesuatu di dalam wadah maka perlu kunci ssh untuk mengakses repo pribadi ini.

Saya belum menemukan cara yang baik dan masuk akal untuk menangani kesulitan ini tanpa mengalahkan beberapa hal lain yang menurut saya bermanfaat tentang buruh pelabuhan (lihat: docker squash ).

Saya sekarang harus mundur dalam membangun bagian-bagian aplikasi di luar wadah dan menggunakan COPY untuk membawa produk akhir ke dalam wadah. meh

Saya pikir docker build memerlukan beberapa fungsi untuk menangani data sementara seperti rahasia sehingga mereka tidak menemukan jalan mereka ke kontainer pengiriman akhir.

Saya pikir build buruh pelabuhan memerlukan beberapa fungsionalitas untuk menangani data singkat seperti rahasia

Ini adalah masalah filosofis yang agak teknis. Data fana semacam itu akan mengalahkan manfaat penting buruh pelabuhan: reproduktifitas.

Filosofi Docker adalah bahwa Dockerfile Anda bersama dengan konteksnya sudah cukup untuk membangun sebuah gambar.
Jika Anda memerlukan konteks di luar gambar yang dihasilkan, Anda harus mengambilnya dari jaringan dan melewatkan penulisan ke sistem file. Karena setiap baris Dockerfile menghasilkan snapshot sistem file.

Jika rahasia tidak boleh menjadi bagian dari suatu gambar, Anda dapat menjalankan wadah sementara, yang akan mencerminkan/memproksi semua sumber daya Anda yang dilindungi rahasia dan memberikan akses tanpa rahasia. Mirroring, btw punya alasan lain: https://developers.slashdot.org/story/16/03/23/0652204/how-one-dev-broke-node-and-thousands-of-projects-in-11-lines -dari-javascript

Anda juga dapat membagikan kunci ssh itu sendiri, tetapi Anda tidak akan dapat mengontrol penggunaannya.

@bhamilton-idexx jika Anda memastikan bahwa otentikasi ke repositori pribadi Anda berfungsi dengan token yang berumur pendek, Anda tidak perlu khawatir tentang rahasia yang dipertahankan dalam gambar buruh pelabuhan.
Anda memiliki sistem build yang menghasilkan token dengan ttl 1 jam, jadikan ini tersedia sebagai variabel lingkungan untuk build buruh pelabuhan.
Build Anda dapat mengambil detail build yang diperlukan, tetapi waktu rahasia akan habis segera setelah build Anda selesai, menutup vektor serangan itu.

Telah membaca banyak utas ini sekarang dan satu fitur yang akan menyelesaikan beberapa kasus penggunaan di sini dan akan memiliki kasus penggunaan di luar rahasia adalah flag --add untuk docker run yang menyalin file ke dalam wadah, seperti pernyataan ADD di Dockerfiles

artikel ini adalah A+ http://elasticcompute.io/2016/01/21/runtime-secrets-with-docker-containers/

Itu memang artikel yang bagus. Bacaan yang sangat bagus. Dan persis seperti hal yang kami harapkan untuk dilihat.

OMONG-OMONG:

Juga menemukan beberapa alat rahasia lain yang tampaknya telah terlewatkan di sana dari artikel tersebut. Mohon maaf jika ada pengulangan/duplikasi. Belum melihat mereka disebutkan di sini:

Membangun rahasia waktu:

https://github.com/defunctzombie/docket

Rahasia waktu berjalan:

https://github.com/ehazlett/docker-volume-libsecret

Apa yang orang pikirkan? Terimakasih banyak.

Untuk saya:

Alat-alat baru ini ^^ terlihat sangat bagus sekarang. Dan mereka pasti tidak ada ketika kami pertama kali memulai tiket ini. TAPI hal utama yang sekarang saya rasakan masih paling hilang:

Memiliki kemampuan yang lebih baik untuk rahasia waktu pembuatan di DockerHub. Yang miskin di sana dan memaksa pilihan baik-atau. Kita harus melupakan manfaat dari satu solusi untuk manfaat yang lain. Bergantung pada rangkaian fitur keseluruhan mana yang lebih penting. Karena bangunan lokal jelas lebih baik untuk menjaga rahasia tetap aman, tetapi dapat dimengerti lebih buruk daripada Dockerhub dengan cara lain.

Kami telah menulis alat lain, mirip dengan map, yang menggunakan format gambar baru:

https://github.com/AngryBytes/docker-surgery

Implementasi kami pertama-tama membuat lapisan yang berisi rahasia yang dikomentari SECRETS , kemudian membuat salinan Dockerfile dengan FROM dimodifikasi, membangun dan akhirnya menghapus semua SECRETS lapisan dari gambar yang dihasilkan.

Selalu ada peringatan untuk meretas ini, dan itu akan membengkak jika buruh pelabuhan memiliki fungsi rebasing atau penyambungan lapisan bawaan. Menghapus lapisan perantara saat ini lambat, karena semua solusi harus melakukan tarian docker save / docker load belakang layar.

Selanjutnya build caching rusak. Saat ini, kami menggunakan docker commit untuk membuat lapisan rahasia yang dikomentari, tetapi menyimpan cache yang tepat dari lapisan ini masih merupakan pekerjaan yang sulit, yang kemungkinan besar tidak akan kami lakukan. Menggunakan Dockerfile untuk membuat lapisan rahasia dapat memecahkan masalah ini, tetapi tidak ada cara untuk mengomentari lapisan tersebut, sehingga sulit untuk menentukan dengan tepat apa yang harus dihapus setelahnya.

@Vanuan [Dockerfile] tidak dapat memiliki reproduktifitas. Perintah RUN menjamin bahwa Anda dan saya tidak dapat mengharapkan untuk mendapatkan gambar yang sama persis dari dua proses. Mengapa? Karena sebagian besar waktu orang menggunakan RUN untuk mengakses sumber daya jaringan. Jika Anda menginginkan gambar yang sama dengan saya, Anda perlu membuat gambar Anda sendiri 'DARI' milik saya. Tidak ada pengaturan lain yang akan memberi kita gambar yang sama. Tidak ada pengaturan lain yang dapat memberi kita gambaran yang sama. Semua reproduktifitas yang tahan lama berasal dari Docker Hub, bukan Dockerfile.

Jika satu-satunya alasan mengapa kami tidak dapat memiliki data ephemeral adalah karena Docker berpikir mereka dapat menghapus semua data ephemeral, maka Anda harus menghentikan instruksi RUN.

@stephank Saya telah menerapkan alat pembangunan buruh pelabuhan di tempat kerja yang mengambil pendekatan yang sedikit berbeda. Perhatian utama saya bukanlah untuk membangun rahasia waktu, tetapi juga menanganinya (menjaga rahasia dari gambar yang dibangun, yaitu, bagaimana Anda mendapatkan rahasia di tempat pertama masih terserah Anda).

Dan itu dengan menjalankan "build manager" dengan kode proyek dalam VOLUME. Manajer kemudian menjalankan sejumlah alat pembangunan dalam wadah terpisah yang memasang kode proyek menggunakan volume dari manajer. Jadi, semua artefak yang dibuat dan file lain yang dihasilkan disimpan dalam volume pengelola dan mengikuti alur pembangunan untuk setiap langkah pembangunan. Pada akhirnya, manajer dapat membangun citra produksi akhir menggunakan hasil build yang dihasilkan. Rahasia apa pun yang diperlukan selama ini telah tersedia di pengelola dan/atau wadah pembuatan, tetapi bukan gambar akhir. Tidak ada sihir gambar buruh pelabuhan yang digunakan, dan cache build berfungsi seperti yang diharapkan.

Seperti apa pipeline build sepenuhnya tergantung pada proyek menggunakan file spesifikasi yang mengonfigurasi persyaratan build.

Sebenarnya, saya agak bersemangat tentang alat ini, saya hanya menunggu kami dapat merilisnya sebagai open source (menunggu pedoman kebijakan perusahaan untuk diadopsi)..

@kaos Di satu sisi, saya tidak ingin menyimpang dari alat Docker stok. Di sisi lain, saya merasa harus ada lebih banyak persaingan di antara alat pembuatan gambar. Jadi kedengarannya menarik! 😀

@thaJeztah untuk

@alexkolson Saya pikir kunci untuk utas ini adalah "JANGAN LAKUKAN INI" kecuali Anda telah mengurangi X, Y, Z. Ini jelas merupakan masalah teknik - akan selalu ada "solusi" untuk masalah umum. Yang mengatakan, pendidikan tentang apa yang tidak boleh dilakukan dan mengapa penting sehingga solusi yang sebenarnya dapat dimulai. Iblis selalu dalam pengaturan default - jadi kami perlu memastikan pengguna baru memahami apa yang berisiko.

Mungkin beberapa dari kalian bisa membantu saya karena saya belum banyak pengalaman dengan buruh pelabuhan.
Saya menggunakan Hashicorps Vault untuk mengambil rahasia saya.

Apa yang pada dasarnya saya lakukan adalah memberikan token sebagai argumen build dan token dapat digunakan untuk mengambil informasi sensitif dari Vault. Ini terjadi pada waktu yang dibangun dan hanya dapat berhasil jika Vault berstatus "tidak disegel" (terbuka untuk mengambil data). Setelah membangun token yang digunakan dicabut.

Tapi saya pikir saya masih menghadapi beberapa masalah umum.

• Saya harus membuat gambar baru jika data sensitif berubah
• Jika gambar saya dicuri / diretas maka data sensitif ada di dalam gambar.

Dimungkinkan untuk menemukan token bekas dengan pemeriksaan buruh pelabuhan tetapi tidak dapat digunakan lagi.
Saya membuat pilihan untuk menyegel dan membuka segel hashicorps vault hanya pada waktu pembuatan untuk membatasi akses di toko rahasia sebanyak mungkin. Saya juga tidak melihat opsi untuk menyimpan rahasia saat mengambil data saat runtime.

Jadi seberapa buruk saya melakukannya (tidak apa-apa untuk mengatakan jika saya mengacaukan waktu;)) adakah yang punya tip dan trik agar saya membuat segalanya lebih aman?

@weemen AFAIK menyimpan rahasia dalam gambar Anda juga bukan ide yang baik. Gambar Anda seharusnya tidak memiliki kredensial yang dimasukkan (termasuk token Vault). Sebagai gantinya, gunakan backend autentikasi app-id Vault untuk container Anda guna mendapatkan rahasia tentang waktu muat. Menyimpannya dalam memori wadah entah bagaimana, tergantung pada tumpukan aplikasi yang Anda gunakan.

Selain itu, Vault sedang mengerjakan backend autentikasi aws yang akan berguna di masa mendatang jika Anda menggunakan AWS sebagai penyedia cloud.

@jaredm4 Bisakah Anda mengklarifikasi pernyataan ini?:

"Sebaliknya, gunakan backend autentikasi id aplikasi Vault untuk wadah Anda untuk mendapatkan rahasia tentang waktu muat. Simpan dalam memori wadah entah bagaimana, tergantung pada tumpukan aplikasi yang Anda gunakan."

Saya belum jelas kapan/di mana mengambil rahasia dari Vault (atau Keywhiz, dll). Apakah ini dilakukan sebelum buruh pelabuhan dijalankan dan diteruskan ke perintah run? Apakah ini terjadi di beberapa titik selama inisialisasi wadah (jika demikian, ada contoh)? Haruskah aplikasi saya mengambil ini saat dibutuhkan? Misalnya, aplikasi Rails saya memerlukan kunci Google API, apakah saya menulis sesuatu di dalam Rails untuk dipanggil ke vault saat kunci diperlukan?

Saya pikir saya jelas tentang perlunya menggunakan sesuatu seperti Vault, dan jelas tentang cara mengonfigurasinya, saya hanya tidak jelas tentang cara menggunakan layanan dan memperbarui file yml saya dan siap ketika Rails boot.

Bimbingan apa pun di sini akan dihargai. Terima kasih

Tentu @mcmatthew , meskipun saya harus

Cara saya mencoba mengkodekannya adalah bahwa satu-satunya info yang Anda berikan ke wadah adalah sesuatu yang diperlukan agar kode Anda dapat diautentikasi dengan Vault. Jika Anda menggunakan backend app-id, itu akan menjadi app-id itu sendiri, dan alamat Vault Anda.

Saat boot kontainer, aplikasi Rails Anda akan melihat bahwa itu belum memiliki rahasia, dan harus mengambilnya dari Vault. Ini memiliki app-id disediakan, dan entah bagaimana harus menghasilkan user-id . Pembuatan ID pengguna ini perlu ditentukan oleh Anda, tetapi dokumentasi mereka mengisyaratkan sebagai "umumnya nilai unik untuk mesin, seperti alamat MAC atau ID instans, atau nilai yang di-hash dari nilai unik ini."

Setelah aplikasi Rails Anda memiliki app-id dan user-id siap, ia kemudian dapat menggunakan API Vault untuk /login. Dari sana Anda kemudian dapat melakukan panggilan API untuk mendapatkan rahasia yang Anda butuhkan.

Sekarang untuk memperjelas apa yang saya maksud tentang menyimpannya dalam memori -- ini bervariasi tergantung pada jenis aplikasi yang Anda gunakan, tetapi dengan Rails harus ada cara untuk menyimpan rahasia Anda dalam cache variabel userland yang memungkinkan Rails mengakses rahasia dari memori setiap permintaan alih-alih mendapatkannya dari Vault berulang-ulang (yang seperti yang dapat Anda bayangkan akan lambat). Lihatlah panduan ini tentang caching di Rails. Yaitu, bagian 2.0, tetapi memastikannya menggunakan memory_cache dan bukan disk.

Terakhir, pastikan bahwa bagaimanapun Anda mengkodekannya, Anda melakukannya di Rails dan bukan dengan skrip titik masuk Docker khusus atau yang serupa. Rails harus mendeteksi rahasia dalam memori, dan jika tidak ada, ambillah.

Saya harap itu membantu. Saya tahu, levelnya sedikit tinggi, tapi beginilah cara kami merencanakan untuk mengatasinya.

Yang tidak jelas adalah apa yang harus dirahasiakan, app-id, user-id atau keduanya.

Oke, jawabannya adalah keduanya https://www.vaultproject.io/docs/auth/app-id.html
Tetapi masih belum jelas mengapa ini lebih aman daripada sekadar akses firewall biasa.
Mungkinkah setiap rahasia host harus diikat dengan rahasia aplikasi (kebijakan)?
Yaitu jika Anda memiliki akses ke rahasia host, Anda akan dapat mengakses aplikasi tertentu jika Anda mengetahui nama rahasianya?

Sekarang kita perlu menyimpan 2 token di suatu tempat?

@Vanuan Keduanya harus dirahasiakan mungkin ya.

Tujuan utama aplikasi-id adalah untuk membatasi akses ke rahasia tertentu di dalam Vault melalui Kebijakan. Siapa pun yang memiliki akses ke app-id memperoleh akses ke rahasia kebijakan app-id itu. App-id harus disediakan oleh strategi penerapan Anda. Misalnya, jika menggunakan Chef, Anda dapat mengaturnya di tas parameter (atau CustomJSON untuk OpsWorks). Namun, dengan sendirinya, itu tidak akan mengizinkan siapa pun mengakses Vault. Jadi seseorang yang mendapatkan akses ke Chef tidak akan dapat mengakses Vault.

User-id TIDAK disediakan oleh Chef, dan harus diikat ke mesin tertentu. Jika aplikasi Anda diskalakan secara berlebihan di seluruh instance, setiap instance harus memiliki user-id sendiri. Tidak masalah dari mana id pengguna ini berasal (meskipun mereka memberikan saran), tetapi tidak boleh berasal dari tempat yang sama dengan yang menyebarkan id aplikasi (yaitu, Chef). Seperti yang mereka katakan, itu bisa ditulis, hanya melalui cara lain. Perangkat lunak apa pun yang Anda gunakan untuk menskalakan instans dapat menyediakan id pengguna ke instans/wadah buruh pelabuhan dan mengotorisasi id pengguna ke id aplikasi. Ini juga dapat dilakukan dengan tangan jika Anda tidak menskalakan instans Anda secara dinamis. Setiap kali manusia menambahkan instance baru, mereka membuat user-id baru, mengotorisasinya ke app-id, dan memasoknya ke instance melalui cara apa pun yang paling cocok untuk mereka.

Apakah ini lebih baik daripada instance firewall? Kira itu tergantung. Firewall tidak membatasi akses ke rahasia di Vault (afaik), dan jika seseorang memperoleh akses ke instance Anda, mereka dapat dengan mudah memasuki Vault Anda.

Dengan cara ini, sulit bagi mereka untuk mendapatkan semua potongan teka-teki. Untuk melangkah lebih jauh, app-id juga memungkinkan blok CIDR yang harus Anda gunakan. Jika seseorang entah bagaimana mendapatkan app-id dan user-id, mereka tetap tidak dapat mengakses Vault tanpa berada di jaringan itu.

(Sekali lagi, ini adalah interpretasi saya setelah mengumpulkan dokumentasi sebaik mungkin)

@Vanuan @mcmatthew pertanyaan bagus! @jaredm4 sangat terima kasih atas klarifikasi ini, ini pasti akan membantu saya. Ini sangat berguna untuk semua orang yang mencari implementasi yang lebih praktis!! Jika saya punya waktu di mana dua minggu mendatang maka saya akan mencoba lagi!

@thaJeztah :

Dapat diakses oleh proses apa pun dalam wadah, sehingga mudah "bocor"

Bisakah Anda mendukung klaim ini? Proses yang tidak memiliki hak istimewa tidak dapat mengakses variabel lingkungan dari proses non-induk. Lihat https://help.ubuntu.com/community/EnvironmentVariables#Process_locality.

Variabel lingkungan ditetapkan untuk wadah (melalui --env atau --env-file ) _are_ dapat diakses oleh proses apa pun dalam wadah.

Tentu saja, karena mereka adalah anak-anak dari proses entry point. Ini adalah tugas dari proses itu, atau Anda jika itu misalnya shell, untuk menghapus variabel lingkungan rahasia sesegera mungkin.

Yang lebih relevan adalah apakah proses dengan ID pengguna yang berbeda selain 0 dapat mengakses variabel lingkungan ini di dalam dan/atau di luar wadah. Ini juga tidak boleh terjadi, ketika perangkat lunak yang Anda gunakan di dalam wadah benar-benar menjatuhkan hak istimewa.

Saya tahu ini di luar topik tetapi adakah orang lain yang memperhatikan bahwa masalah ini telah aktif selama hampir satu tahun penuh sekarang! Besok adalah hari jadinya. 👏

Apakah mungkin bagi proses wadah untuk membaca variabel env dalam memori proses dan kemudian menghapusnya (di lingkungan)? Apakah ini memperbaiki sebagian besar masalah keamanan run-time?

@davibe masalahnya adalah jika wadah atau prosesnya dimulai ulang, env vars itu kemudian hilang, tanpa cara untuk memulihkannya.

Saya mencoba tetapi sepertinya env vars masih ada setelah diluncurkan kembali.

dade<strong i="6">@choo</strong>:~/work/grocerest(master)$ cat test.js
console.log("FOO value: " + process.env.FOO);
delete(process.env.FOO);
console.log("FOO value after delete: " + process.env.FOO);

dade<strong i="7">@choo</strong>:~/work/grocerest(master)$ docker run --name test -it -e FOO=BAR -v $(pwd):/data/ node node /data/test.js
FOO value: BAR
FOO value after delete: undefined

dade<strong i="8">@choo</strong>:~/work/grocerest(master)$ docker restart test
test

dade<strong i="9">@choo</strong>:~/work/grocerest(master)$ docker logs test
FOO value: BAR
FOO value after delete: undefined
FOO value: BAR
FOO value after delete: undefined

mungkin docker-run menjalankan hal saya sebagai anak dari bash ? menurut saya sebaiknya tidak..

@davibe :

unset 'SECRET_ENV_VAR'

Saya pikir masalah/fitur utama dalam semua ini adalah Anda masuk ke Docker sebagai root , sehingga apa pun yang Anda masukkan ke dalam wadah dapat diperiksa, baik itu token, volume, variabel, kunci enkripsi. .. apa pun.

Jadi satu ide adalah menghapus sudo dan su dari wadah Anda dan menambahkan perintah USER sebelum ENTRYPOINT atau CMD . Siapa pun yang menjalankan wadah Anda sekarang seharusnya tidak mendapatkan kesempatan untuk menjalankan sebagai root (jika saya tidak salah) dan dengan demikian Anda sekarang dapat benar-benar menyembunyikan sesuatu darinya.

Ide lain (IMHO terbaik) adalah menambahkan gagasan pengguna dan grup ke soket Docker dan ke wadah, sehingga Anda dapat memberi tahu GROUP-A memiliki akses ke wadah dengan TAG-B, dan USER-C milik GROUP- A sehingga memiliki akses ke wadah tersebut. Bahkan bisa berupa izin per operasi (GROUP-A memiliki akses untuk memulai/berhenti untuk TAG-B, GROUP-B memiliki akses ke exec, GROUP-C memiliki akses ke rm/inspect, dan seterusnya).

Setelah meneliti ini selama beberapa jam, saya tidak percaya bahwa tampaknya tidak ada solusi atau solusi yang direkomendasikan secara resmi untuk rahasia waktu pembuatan, dan sesuatu seperti https://github.com/dockito/vault tampaknya menjadi satu-satunya pilihan yang layak untuk rahasia waktu pembuatan (singkat dengan meremas seluruh gambar yang dihasilkan atau membangunnya secara manual sejak awal). Sayangnya https://github.com/dockito/vault cukup spesifik untuk kunci ssh, jadi saya pergi untuk mencoba mengadaptasinya untuk hosting file penyimpanan kredensial git https juga ...

Setelah apa yang tampak seperti selamanya (awalnya saya mendengar itu dijadwalkan untuk rilis Q4 2015), AWS ECS tampaknya akhirnya memenuhi janji mereka untuk membawa peran IAM ke aplikasi buruh pelabuhan . Ini juga postingan blognya .

Sepertinya ini dikombinasikan dengan beberapa kebaikan KMS adalah solusi jangka pendek yang layak. Secara teori, Anda hanya perlu membuat rahasia terikat pada peran prinsipal/IAM tertentu agar peran non-auth tidak meminta sesuatu yang tidak seharusnya dan menyerahkan penyimpanan yang aman ke KMS.

Belum mencobanya, tetapi ada di daftar pendek saya ...

Kubernetes juga tampaknya memiliki beberapa penanganan rahasia yang mengingatkan saya pada banyak kantong data terenkripsi Chef.

Saya mengerti ini bukan cara OSS yang tidak bergantung pada platform yang merupakan inti dari utas ini,
tetapi ingin membuang dua opsi itu di luar sana untuk orang-orang yang bermain di ruang infrastruktur yang membutuhkan sesuatu _NOW_

Saya baru saja menemukan sesuatu yang mungkin membantu dalam hal ini: https://github.com/docker/docker/pull/13587

Sepertinya ini tersedia mulai dengan buruh pelabuhan v1.10.0, tetapi saya belum menyadarinya sampai sekarang. Saya pikir solusi yang saya condongkan pada saat ini adalah menggunakan https://www.vaultproject.io/ untuk menyimpan dan mengambil rahasia, menyimpannya di dalam wadah dalam sistem file tmpfs yang dipasang ke /secrets atau semacamnya . Dengan fitur ECS baru yang mengaktifkan peran IAM pada container, saya yakin saya harus dapat menggunakan autentikasi AWS EC2 vault untuk mengamankan otorisasi ke rahasia itu sendiri. (Untuk platform independen, saya mungkin cenderung menggunakan autentikasi ID Aplikasi mereka.)

Bagaimanapun, bagian yang hilang bagi saya adalah tempat menyimpan rahasia dengan aman setelah diambil. Opsi tmpfs sepertinya bagus untuk saya. Satu-satunya hal yang hilang adalah bahwa ECS tampaknya belum mendukung parameter ini, itulah sebabnya saya mengirimkan ini hari ini: https://github.com/aws/amazon-ecs-agent/issues/469

Semua bersama-sama itu sepertinya solusi yang cukup komprehensif IMHO.

@CameronGo , terima kasih atas penunjuknya. Jika saya mengerti dengan benar ini tidak dapat digunakan di build dengan baik, atau bisakah?

@NikolausDemmel maaf ya, Anda benar. Ini hanya solusi untuk rahasia waktu berjalan, bukan waktu pembuatan. Di lingkungan kami, rahasia waktu pembuatan hanya digunakan untuk mengambil kode dari Git. Jenkins menangani ini untuk kami dan menyimpan kredensial untuk akses Git. Saya tidak yakin solusi yang sama memenuhi kebutuhan semua orang di sini, tetapi saya tidak jelas tentang kasus penggunaan lain untuk rahasia waktu pembuatan.

Jenkins menangani ini untuk kami dan menyimpan kredensial untuk akses Git.

Bagaimana cara kerjanya dengan buruh pelabuhan? Atau apakah Anda tidak git clone di dalam wadah itu sendiri?

Setelah membaca masalah ini secara lengkap, saya yakin ini akan sangat bermanfaat jika dibagi menjadi masalah terpisah untuk rahasia "waktu pembuatan" dan "waktu berjalan", yang memiliki persyaratan yang sangat berbeda

Jika Anda seperti saya dan Anda datang ke sini mencoba memutuskan apa yang harus dilakukan sekarang, maka FWIW saya akan menjelaskan solusi yang saya tetapkan, sampai sesuatu yang lebih baik muncul.

Untuk rahasia run-time, saya memutuskan untuk menggunakan http://kubernetes.io/docs/user-guide/secrets/. Ini hanya berfungsi jika Anda menggunakan kubernetes. Kalau tidak, brankas terlihat baik-baik saja. Rahasia apa pun baik dalam gambar yang dihasilkan atau lapisan sementara adalah ide yang buruk.

Mengenai rahasia waktu pembuatan - Saya tidak dapat memikirkan kasus penggunaan rahasia waktu pembuatan lainnya selain mendistribusikan kode pribadi. Pada titik ini, saya tidak melihat solusi yang lebih baik daripada mengandalkan melakukan sesuatu "rahasia" di sisi Host, dan TAMBAHKAN paket/jar/roda/repo/dll yang dihasilkan. ke gambar. Menyimpan satu LOC yang menghasilkan paket di sisi host tidak sepadan dengan risiko mengekspos kunci ssh atau kerumitan menjalankan server proxy seperti yang disarankan dalam beberapa komentar.

Mungkin menambahkan flag "-v" ke build docker, mirip dengan flag docker run bisa berfungsi dengan baik? Itu akan sementara berbagi direktori antara Host dan gambar, tetapi juga memastikan itu akan tampak kosong di cache atau di gambar yang dihasilkan.

Saat ini saya sedang mengerjakan solusi menggunakan Vault :

1. Mesin pembuat telah menginstal Vault dan memiliki token yang disimpan secara lokal
2. Saat build dimulai, mesin builder meminta token sementara baru yang hanya valid selama beberapa menit (berdasarkan build, 1 jam bahkan dapat diterima)
3. Menyuntikkan token sebagai build arg
4. Gambar Docker juga telah menginstal Vault (atau menginstal dan menghapusnya selama pembuatan) dan menggunakan token ini dapat mengambil rahasia sebenarnya

Penting bahwa rahasia dihapus dalam perintah yang sama, jadi ketika buruh pelabuhan men-cache lapisan yang diberikan tidak ada sisa. (Ini tentu saja hanya berlaku untuk membangun rahasia waktu)

Saya belum membangun ini, tetapi sedang mengerjakannya.

Agak terkait dengan komentar @kozikow : "Mengenai rahasia waktu pembuatan - Saya tidak dapat memikirkan kasus penggunaan rahasia waktu pembuatan lainnya selain mendistribusikan kode pribadi."

Mungkin bukan rahasia waktu pembuatan secara khusus, tetapi saya memiliki kebutuhan kasus penggunaan untuk (mengamankan) kata sandi selama waktu pembuatan di Dockerfile agar artefak yang sudah dibuat dapat diunduh melalui perintah RUN curl. Unduhan waktu pembuatan memerlukan kredensial pengguna untuk mengautentikasi untuk mengambil artefak - jadi kami meneruskan kata sandi sebagai variabel lingkungan di Dockerfile sekarang (kami masih di Dev). Build terjadi di belakang layar secara otomatis, saat kita menggunakan OpenShift, dan variabel lingkungan di Dockerfile adalah output ke log selama build, seperti perintah build docker. Ini membuat kata sandi terlihat oleh siapa saja yang memiliki akses ke log, termasuk pengembang kami. Saya sudah mati-matian mencoba mencari cara untuk mengirim kata sandi sehingga dapat digunakan selama pembuatan buruh pelabuhan, tetapi kemudian tidak memiliki keluaran kata sandi ke log atau akhirnya berada di lapisan mana pun.

Saya juga mendukung apa yang dikatakan

Saya pikir mungkin bermanfaat untuk mendefinisikan beberapa tes untuk mekanisme rahasia (runtime) apa pun yang dibuat oleh siapa pun. Karena ada banyak orang di utas ini yang menganjurkan keamanan yang sangat lemah.

Sebagai permulaan saya menyarankan:

• Rahasianya tidak muncul di inspeksi buruh pelabuhan
• Setelah proses 1 dimulai, rahasia tidak tersedia dalam file apa pun yang dapat diakses dari wadah (termasuk file yang dipasang volume)
• Rahasianya tidak tersedia di /proc/1/cmdline
• Rahasia ditransmisikan ke wadah dalam bentuk terenkripsi

Setiap solusi yang disarankan di atas yang melanggar salah satunya bermasalah.

Jika kita dapat menyepakati definisi tentang perilaku apa yang harus diikuti oleh sebuah rahasia, maka setidaknya itu akan menyingkirkan solusi tanpa akhir yang tidak sesuai dengan tujuan.

@gtmtech saran bagus :)

Setelah proses 1 dimulai, rahasia tidak tersedia dalam file apa pun yang dapat diakses dari wadah (termasuk file yang dipasang volume)

Saya tidak yakin saya setuju dengan ini. Meskipun saya setuju itu hanya dapat diakses dari wadah (idealnya dalam memori) ada beberapa kasus di mana aplikasi membutuhkan waktu untuk "memulai" dan tidak menghapus file dari bawahnya. Saya pikir sesuatu dalam memori selama menjalankan wadah (dihapus saat berhenti) adalah pendekatan yang sedikit lebih baik.

Saya akan menambahkan ke daftar persyaratan run-time:

• Otentikasi/otorisasi kontainer saat mem-bootstrap rahasia pertama.

Misalnya, Vault memberikan otorisasi dengan AppRole Backend tetapi terbuka tentang bagaimana container mengidentifikasi diri mereka sendiri.

Nick Sullivan mempresentasikan proyek PAL Clouflare beberapa minggu yang lalu, berjanji untuk segera membukanya, yang akan memberikan satu jawaban potensial untuk pertanyaan otentikasi menggunakan notaris buruh pelabuhan.

Dari perspektif aplikasi, ada tiga cara untuk menangani hal ini:

1. Dapatkan rahasia dari variabel lingkungan.
2. Dapatkan rahasia dari file.
3. Dapatkan rahasia dari sistem lain.

1 dan #2 di atas umumnya yang paling umum karena mayoritas aplikasi mendukung mekanisme ini. #3 mungkin lebih ideal karena meninggalkan "remah" paling sedikit, tetapi aplikasi harus dikembangkan secara khusus untuk ini dan seringkali masih harus memiliki kredensial untuk mendapatkan rahasianya.

Docker adalah tentang keserbagunaan dan mendukung berbagai kasus penggunaan. Atas dasar ini 1. dan 2. paling menarik dari pandangan aplikasi, meskipun faktanya keduanya meninggalkan "remah" pada sistem.

Salah satu pendekatan umum yang pasti saya gunakan adalah menyuntikkan rahasia melalui skrip titik masuk (mis., gunakan alat seperti credstash atau KMS biasa di AWS dan gabungkan dengan peran IAM). Dalam hal ini Anda benar-benar melakukan # 3 di atas dalam skrip titik masuk, dan melakukan # 1 (mengatur variabel lingkungan) atau # 2 (menulis ke file). Pendekatan ini dinamis dan untuk #1 (variabel lingkungan), tidak mengekspos kredensial di log buruh pelabuhan atau pemeriksaan buruh pelabuhan.

Hal yang menyenangkan tentang pendekatan titik masuk adalah Anda memisahkan masalah manajemen rahasia dari aplikasi.

Ini adalah area di mana Docker dapat menambahkan fungsionalitas untuk menghindari keharusan menggunakan skrip titik masuk roll Anda sendiri. Docker menyukai plugin dan dapat memberikan pengait ke dalam siklus hidup container di mana ia dapat mendukung plugin penyedia "rahasia", yang pada dasarnya menjalankan fungsi skrip titik masuk manual dan menyuntikkan rahasia ke dalam wadah (melalui variabel atau file lingkungan internal). Jadi, Anda dapat memiliki penyedia rahasia Hashicorp Vault, penyedia rahasia AWS KMS, dll. Docker mungkin dapat memiliki penyedianya sendiri yang berbasis menggunakan enkripsi RSA (melalui sertifikat digital). Seluruh konsep ini secara longgar mirip dengan konsep rahasia Kubernetes, yang menyajikan rahasia pada sistem file kontainer.

Tentu saja ada kerumitan bagaimana Anda mengotorisasi akses ke penyedia rahasia, yang merupakan masalah yang Anda hadapi hari ini. Dengan Hashicorp Anda dapat mengeluarkan dan memberikan token satu kali/waktu terbatas untuk autentikasi, dengan AWS itu adalah peran IAM, dengan pendekatan enkripsi Docker RSA yang saya sebutkan, itu mungkin hanya meneruskan rahasia yang dienkripsi menggunakan sertifikat publik Docker Engine.

Benang ini bagus. Saya harap kita melihat lebih banyak utas seperti ini di mana orang-orang dari komunitas dan semua lapisan profesi dapat berbagi pengalaman, pemikiran, dan solusi mereka.

Masalah "nol rahasia" adalah masalah yang rumit. Build-time atau run-time? Keduanya memiliki pro dan kontra, dan langkah-langkah dan kelemahan keamanan yang jelas (dan peretasan dan penyelesaian!).

Yang mengatakan, saya telah banyak berpikir tentang bagaimana pengelolaan pass/key turun ke aplikasi dan/atau layanan.

Sesuatu yang akan kami kerjakan dalam beberapa bulan mendatang adalah membangun layanan dukungan konfigurasi global bersama melalui pasangan kunci/nilai, didistribusikan oleh Konsul dan tersedia sebagai variabel lingkungan (atau disuntikkan jika menggunakan variabel lingkungan tidak didukung). Ini hanya mendukung nilai tidak aman Anda. Untuk keamanan, kami akan pindah ke Vault dan memperlakukannya seperti layanan dukungan - seperti database atau ketergantungan lainnya.

Kode, konfigurasi, dan rahasia akan diberikan melalui layanan dukungan. Dalam hal ini, kami menggunakan Stash, Consul, dan Vault. Selama ketergantungannya habis, begitu juga kemampuan untuk menarik konfigurasi dan rahasia sesuai kebutuhan.

Saya belum pernah melihat ini sebagai solusi yang solid di mana pun, maka saya mempostingnya di sini. Tetapi untuk mengembalikannya ke tujuan utas ini, ini adalah salah satu pendekatan yang akan kami coba untuk mengatasi masalah Docker/rahasia. Kami akan membangun aplikasi yang mendukung ini secara asli, daripada mengandalkan kerangka kerja dan platform di sekitar mereka di mana mereka berjalan.

Berkenaan dengan rahasia waktu pembuatan, direktif MOUNT Rocker telah terbukti berguna untuk membuat direktori dan file sementara yang _only_ ada pada waktu pembuatan. Beberapa fitur templating mereka juga dapat membantu dalam situasi ini, tetapi saya belum sepenuhnya menggunakannya.

Saya ingin melihat fungsionalitas ini diimplementasikan sebagai plugin Builder di inti Docker (serta beberapa fitur berguna lainnya yang dimiliki Rockerfiles)!

Saya melihat semua 4 proposal saat ini di OP adalah tentang penyimpanan rahasia

Saya akan mengatakan buruh pelabuhan harus memfasilitasi meneruskan rahasia/kata sandi ke _docker instance_ tetapi menyimpan/mengelola rahasia ini (dan seharusnya) di luar ruang lingkup buruh pelabuhan.

Ketika _melewati secret_ saya akan mengatakan parameter run hampir sempurna kecuali bahwa ini biasanya dicatat. Jadi saya akan mempersempit ini menjadi fitur parameter non-plaintext . Pendekatannya adalah menggunakan enkripsi dengan kunci yang dihasilkan per instance buruh pelabuhan.

Adapun _cara mengelola rahasia_, saya akan mengatakan apa pun yang diinginkan pengguna, dari skrip bash homebrew hingga integrasi oleh perangkat lunak seperti Kubernetes .

Apa yang salah dengan hanya mengimplementasikan MOUNT seperti rocker mount seperti yang dikatakan @agilgur5 sebelumnya? Saya tidak percaya perdebatan ini telah berlangsung begitu lama sehingga sebuah tim harus secara efektif memotong perintah docker build untuk memenuhi kasus penggunaan yang sangat mudah ini. Apakah kita memerlukan server HTTP lain dalam campuran? CIUMAN.

Saya menghabiskan begitu banyak waktu di sekitar subjek ini ...

Untuk saat ini, cara terbaik yang saya temukan untuk mengelola rahasia selama fase build adalah membangun dalam dua langkah, jadi dua file buruh pelabuhan. Berikut contoh yang bagus.

[Habitus] (http://www.habitus.io/) tampaknya menjadi opsi lain, tetapi dalam kasus saya, saya tidak ingin menambahkan alat lain terutama karena saya ingin proses pembuatan di server CI DAN di komputer pengguna tetap sederhana / sama.

Dan bagaimana dengan cara buruh pelabuhan (dind)?

Berikut contoh dua langkah membangun dengan dind seperti yang baru saja saya bicarakan di atas: https://github.com/BenoitNorrin/docker-build-with-secrets

Jangan ragu untuk berkomentar...

Menarik. Agak mengingatkan saya tentang bagaimana OpenShift membangun.

Sepertinya Anda memberikan kata sandi di baris perintah. Apakah ada jalan lain untuk itu?

Perhatikan bahwa ada PR yang sedang dikerjakan untuk rahasia waktu pembuatan di sini; https://github.com/docker/docker/pull/28079 (rahasia runtime untuk layanan akan ada di docker 1.13, lihat https://github.com/docker/docker/pull/27794)

@thaJeztah :
Tentang #28079, saya sedikit pesimis ketika melihat begitu banyak PR seputar masalah ini yang gagal selama dua tahun terakhir ...
Saya tidak ingin memiliki swarm sebagai ketergantungan. Sebagian dari pelanggan saya menggunakan orkestra cluster lain.

@cassiussa :
Saya tidak mengerti apa yang Anda maksud?
1/ Kata sandi diteruskan ke "pembuat wadah" yang bukan gambar akhir. Builder ini melakukan docker build dan menghasilkan image berdasarkan Dockerfile.realease. Tidak ada rahasia yang tersimpan dalam sejarah gambar terakhir ini.
2/ Jangan ragu untuk menggunakan docker-compose ( contoh ) jika Anda tidak ingin meneruskan kata sandi ke baris perintah

@BenoitNorrin Saya pikir ini dapat diperluas ke non-swarm di masa depan, tetapi @diogomonica mungkin tahu lebih banyak tentang itu

Kedengarannya seperti itu:

Saat ini hanya untuk mode Swarm karena backing store adalah Swarm dan karena itu hanya untuk Linux. Ini adalah dasar untuk dukungan rahasia di masa depan di Docker dengan peningkatan potensial seperti dukungan Windows, toko dukungan yang berbeda, dll.

Akan lebih bagus jika diimplementasikan dengan cara yang sama seperti rocker, bisa
sederhana, tidak perlu menjadi 'perusahaan'.

Pada Selasa, 29 Nov 2016, 15:53 ​​Michael Warkentin, [email protected]
menulis:

Kedengarannya seperti itu:

Saat ini hanya untuk mode Swarm karena backing store adalah Swarm dan sebagai
seperti itu hanya untuk Linux. Ini adalah dasar untuk dukungan rahasia di masa depan
Docker dengan peningkatan potensial seperti dukungan Windows, berbeda
toko pendukung, dll.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/13490#issuecomment-263608915 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAZk5vlLwsBHHTTbUS_vvx-qTuwnkp6Oks5rDEpjgaJpZM4Eq021
.

Solusinya adalah mengenkripsi beberapa bagian informasi yang diteruskan dari file docker-compose .

Misalnya, jalankan docker inspect dan informasi terenkripsi akan ditampilkan/ditandai sebagai _encrypted_. Kemudian docker inspect --encryption-key some_key_file akan menampilkan semua info terenkripsi, tidak terenkripsi.

Di sisi lain, di dalam aplikasi kontainer harus dapat menerapkan mekanisme yang berbeda untuk mengakses dan mendekripsi info terenkripsi ini untuk digunakan.

Saya pikir enkripsi _adalah kuncinya_ :)

Tujuannya adalah agar use case saya (sangat, sangat, sangat umum) adalah build a
proyek perangkat lunak dari server git yang memerlukan otentikasi, baik untuk
proyek dan ketergantungannya. Rocker telah memakunya dengan mengizinkan untuk memasang
file atau direktori selama pembuatan (dalam hal ini soket agen SSH)

Pada Selasa, 3 Januari 2017, 04:14 Hisa, [email protected] menulis:

Solusinya adalah mengenkripsi beberapa bagian informasi yang diteruskan
dari file komposisi buruh pelabuhan.

Misalnya, jalankan pemeriksaan buruh pelabuhan dan informasi terenkripsi seharusnya
ditampilkan/ditandai sebagai terenkripsi . Kemudian buruh pelabuhan memeriksa --encryption-key
some_key_file akan menampilkan semua info terenkripsi, tidak terenkripsi.

Di sisi lain, di dalam aplikasi kontainer harus dapat mengimplementasikan
mekanisme yang berbeda untuk mengakses dan mendekripsi informasi terenkripsi ini untuk digunakan.

Saya pikir enkripsi adalah kuncinya :)

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/13490#issuecomment-270049742 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAZk5qEphZo5SR9vOWVL5dck50EPadpVks5rOcsUgaJpZM4Eq021
.

Karena saya tidak melihatnya disebutkan, inilah artikel bagus lainnya tentang menangani rahasia di AWS ECS: https://aws.amazon.com/blogs/security/how-to-manage-secrets-for-amazon-ec2-container- aplikasi-berbasis-layanan-oleh-menggunakan-amazon-s3-and-docker/

Ada perintah "rahasia buruh pelabuhan" baru di Docker 1.13. Masalah ini harus dapat ditutup ketika dokumentasi untuk fitur tersebut memadai untuk kasus penggunaan yang disebutkan di sini.

Perintah rahasia buruh pelabuhan tampaknya hanya berlaku saat ini untuk Docker Swarm (yaitu layanan buruh pelabuhan) sehingga saat ini tidak layak untuk wadah Docker generik.

Juga docker secret hanya mengelola rahasia waktu berjalan, bukan rahasia waktu pembuatan.

Wow. Sepertinya tidak ada seorang pun di tim manajemen produk yang pernah mempertimbangkan
kasus penggunaan di mana apa pun kecuali perangkat lunak sumber terbuka yang tidak diautentikasi mendapat
dibangun dalam wadah buruh pelabuhan atau bahasa apa pun selain golang, di mana semua
dependensi disalin dan ditempel, maaf, 'berversi' ke dalam repo Git.

Aku hanya tidak bisa mengerti bagaimana orang-orang akan menjadi sangat tumpul. Hanya
penjelasan yang dapat saya pikirkan adalah bahwa tim manajemen produk tidak
praktisi dan belum pernah menggunakan produk tersebut. Saya sering melihat ini
karakteristik memanifestasikan dirinya ketika organisasi mempekerjakan atas dasar
keterampilan jira / tangkas.

Saya akan terus menggunakan rocker sampai 2019 atau kapan pun seseorang melihatnya masuk akal.

Pada Minggu, 22 Jan 2017, 23:47 Shane StClair, [email protected] menulis:

Juga rahasia buruh pelabuhan hanya mengelola rahasia waktu berjalan, bukan membangun rahasia waktu.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

Saya mengambil kembali komentar terakhir itu, maaf, saya melampiaskan. Hanya frustrasi itu
kasus tepi sederhana sering tampak seperti kesempatan untuk mengecoh sesuatu
suka konsul atau buat sesuatu yang benar-benar over-engineered daripada hanya
mengimplementasikan sesuatu yang sederhana seperti build time mount.

Pada Senin, 23 Januari 2017, 09:31 Bryan Hunt, [email protected] menulis:

Wow. Sepertinya tidak ada seorang pun di tim manajemen produk yang pernah mempertimbangkan
kasus penggunaan di mana apa pun kecuali perangkat lunak sumber terbuka yang tidak diautentikasi mendapat
dibangun dalam wadah buruh pelabuhan atau bahasa apa pun selain golang, di mana semua
dependensi disalin dan ditempel, maaf, 'berversi' ke dalam repo Git.

Aku hanya tidak bisa mengerti bagaimana orang-orang akan menjadi sangat tumpul. Hanya
penjelasan yang dapat saya pikirkan adalah bahwa tim manajemen produk tidak
praktisi dan belum pernah menggunakan produk tersebut. Saya sering melihat ini
karakteristik memanifestasikan dirinya ketika organisasi mempekerjakan atas dasar
keterampilan jira / tangkas.

Saya akan terus menggunakan rocker hingga 2019 atau kapan pun seseorang melihatnya masuk akal
kemudian.

Pada hari Minggu, 22 Jan 2017, 23:47 Shane StClair, [email protected]
menulis:

Juga rahasia buruh pelabuhan hanya mengelola rahasia waktu berjalan, bukan membangun rahasia waktu.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

@binarytemple Semua orang menginginkan semua fitur sekarang. Jika barang belum siap maka itu belum siap. Membatasi cakupan fitur baru jelas bukan hal yang buruk karena bahkan dengan cakupan terbatas selalu ada ruang untuk perbaikan.

Jika seseorang benar-benar ingin mendapatkan fitur, mereka harus berbicara dengan pengelola tentang bagaimana mereka dapat berkontribusi untuk itu.

Saya memikirkan hal yang sama dengan @mixja bahwa perintah secret hanya membantu pengguna swarm bukanlah solusi yang lebih umum (seperti yang mereka lakukan dengan melampirkan volume persisten). Bagaimana Anda mengelola rahasia Anda (apa itu dan siapa yang memiliki akses ke sana) sangat bergantung pada sistem dan bergantung pada bit berbayar dan/atau OSS mana yang Anda buat bersama untuk membuat "platform" Anda. Dengan Docker, perusahaan bergerak untuk menyediakan platform, saya tidak terkejut bahwa implementasi pertama mereka berbasis swarm seperti halnya Hashicorp mengintegrasikan Vault ke Atlas -- itu masuk akal.

Sungguh bagaimana rahasia dilewatkan berada di luar ruang docker run . AWS melakukan hal semacam ini dengan peran dan kebijakan untuk memberikan/menolak izin plus SDK. Chef melakukannya menggunakan kantong data terenkripsi dan "bootstrapping" crypto ke auth. K8S memiliki versi mereka sendiri dari apa yang baru saja dirilis di 1.13. Saya yakin mesos akan menambahkan implementasi serupa pada waktunya.

Implementasi ini tampaknya jatuh ke dalam 2 kubu.
1) berikan rahasia melalui volume mount yang disediakan oleh "platform" atau (chef/docker secret/k8s
2) berikan kredensial untuk berbicara dengan layanan eksternal untuk mendapatkan sesuatu saat boot (iam/credstash/etc)

Saya pikir saya berharap untuk melihat sesuatu yang lebih sejalan dengan opsi kedua. Pada opsi pertama, saya tidak berpikir ada cukup pemisahan masalah (hal yang melakukan peluncuran juga memiliki akses ke semua kunci), tetapi ini adalah preferensi, dan seperti yang lainnya dalam pembangunan sistem, semua orang suka melakukannya secara berbeda .

Saya didorong bahwa langkah pertama ini telah diambil oleh buruh pelabuhan dan berharap bahwa mekanisme yang lebih umum untuk docker run keluar dari ini (untuk mendukung kamp #2) -- yang sayangnya berarti saya tidak berpikir utas ini misi awal telah terpenuhi dan tidak boleh ditutup.

Suka!
desain yang sangat sederhana namun sangat efektif

@bacoboy , @mixja -
docker swarm init , layanan buruh pelabuhan buat replika=1

bagi saya logis bahwa kawanan buruh pelabuhan akan menjadi default untuk menjalankan wadah/layanan mulai sekarang.

Apakah saya benar dalam berpikir bahwa proposal berbasis swarm baru ini hanya berdampak pada rahasia run-time? Saya benar-benar tidak melihat perlunya penanganan khusus run-time secret, karena sudah ada banyak cara untuk memasukkan secret ke dalam running container.

rahasia build- time itu penting, dan sejauh yang saya tahu, proposal ini tidak membahasnya.

Untuk menyuntikkan rahasia waktu pembuatan, sekarang kita dapat menggunakan docker build --squash untuk melakukan hal berikut dengan aman:

COPY ssh_private_key_rsa /root/.ssh/id_rsa
RUN git pull ...
RUN rm -rf /root/.ssh/id_rsa

Bendera --squash akan menghasilkan satu lapisan untuk seluruh Dockerfile: tidak akan ada jejak rahasia.

--squash tersedia di docker-1.13 sebagai flag eksperimental.

@hmalphettes Ini berarti Anda kehilangan manfaat dari berbagi lapisan bawah di antara build.

Ini jelas bukan niat squash. Aku masih sangat berhati-hati dalam menambahkan rahasia seperti ini.

@zoidbergakan lapisan bawah masih dibagikan.

Saya setuju 100% dengan @ cpuguy83. Mengandalkan flag waktu pembuatan untuk menjaga kerahasiaan akan sangat berisiko. Ada proposal PR untuk waktu pembuatan ( https://github.com/docker/docker/pull/30637 ) Saya akan mengerjakan rebase untuk mendapatkan lebih banyak umpan balik.

@wpalmer Jika Anda memiliki pembuatan gambar otomatis, perkakas Anda harus tahu cara mendapatkan rahasia waktu pembuatan.

Misalnya, Anda mungkin ingin menyimpan rahasia waktu pembuatan Anda di brankas terenkripsi yang memungkinkan dimasukkan ke dalam gambar dan memberikan wadah yang berjalan dari gambar tersebut akses ke rahasia waktu proses yang menyimpan kata sandi lemari besi Anda.

WDYT?

Mengapa kami terus membingungkan rahasia waktu pembuatan dengan rahasia waktu proses? Sudah ada banyak cara bagus untuk buruh pelabuhan (atau alat terkait seperti kubernetes) untuk menyediakan rahasia runtime. Satu-satunya hal yang benar-benar hilang adalah rahasia waktu pembuatan. Rahasia ini tidak digunakan selama waktu berjalan, mereka digunakan selama waktu penginstalan, ini bisa berupa repositori internal misalnya. Satu-satunya cara kerja yang saya lihat dalam topik ini dan terkait (tetapi juga disarankan untuk tidak melakukannya), adalah mengekspos server http ke wadah selama waktu pembuatan. Pendekatan server http membuat segalanya menjadi rumit untuk benar-benar mendapatkan rahasia itu.

+1 rahasia waktu pembuatan != rahasia waktu berjalan

Seperti yang ditunjukkan Paulus. Tidak diinginkan untuk memanggang repositori internal
kredensial ke dalam gambar.

Mengapa ini begitu sulit untuk dipahami?

Pada Kam, 16 Feb 2017, 14:42 Paul van der Linden, [email protected]
menulis:

Mengapa kami terus membingungkan rahasia waktu pembuatan dengan rahasia waktu proses? Di sana
sudah banyak cara bagus untuk buruh pelabuhan (atau alat terkait seperti kubernetes) untuk
memberikan rahasia runtime. Satu-satunya hal yang benar-benar hilang adalah waktu pembuatan
rahasia. Rahasia ini tidak digunakan selama waktu berjalan, mereka digunakan selama
waktu instal, ini bisa berupa repositori internal misalnya. Satu-satunya
cara kerja yang saya lihat dalam topik ini dan terkait (tetapi juga disarankan
menentangnya), mengekspos server http ke wadah selama waktu pembuatan.
Pendekatan server http membuat segalanya menjadi rumit untuk benar-benar dicapai
rahasia-rahasia itu.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/13490#issuecomment-280348116 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAZk5h0Z2OGwApVnLNEFWKRdOfGxLOmRks5rdGBagaJpZM4Eq021
.

@pvanderlinden Anda juga dapat melakukannya dengan membangun dua langkah.
Berikut contohnya: https://github.com/BenoitNorrin/docker-build-with-secrets

@timka seperti yang disebutkan, tidak diinginkan untuk memasukkan kredensial ke dalam gambar karena menimbulkan risiko keamanan. Berikut ini proposal untuk rahasia waktu pembuatan: https://github.com/docker/docker/pull/30637

@BenoitNorrin Tidak yakin bagaimana dalam kasus penggunaan saya (dan lainnya).
Paket-paket yang perlu diinstal sudah dibangun ketika saya memulai proses pembangunan buruh pelabuhan. Tetapi pembangunan buruh pelabuhan perlu menginstal paket-paket ini, itu akan membutuhkan akses ke repositori anaconda internal dan/atau server pypi (python). Lokasi dan kata sandi tentu saja bersifat pribadi.
Sepertinya #30637 adalah upaya lain, semoga ini akan berakhir di buruh pelabuhan!

@timka paruh pertama pesan Anda tampaknya menyebutkan rahasia waktu pembuatan, tetapi paruh kedua secara eksplisit berbicara tentang rahasia waktu proses. Rahasia run-time sederhana. "Solusi" saya saat ini untuk rahasia waktu pembuatan adalah dengan menjalankan sebelumnya, sebagai langkah yang sepenuhnya terpisah, sebuah wadah yang mengambil data pribadi menggunakan rahasia waktu proses. Langkah lain kemudian menggabungkan ini ke dalam pohon, sebelum menjalankan perintah docker build .

Alternatifnya, jika rahasia waktu pembuatan adalah fitur standar, adalah menjalankan langkah-langkah ini di dalam Dockerfile.

Perkakas saya memang tahu cara menjalankan langkah-langkah ini secara otomatis, tetapi saya perlu memanggangnya sendiri, yang agak tidak masuk akal untuk keinginan yang sama.

FYI, saya menulis https://github.com/abourget/secrets-bridge untuk mengatasi masalah rahasia waktu pembuatan.

Ini menciptakan konfigurasi sekali pakai yang dapat Anda berikan sebagai argumen, selama proses pembuatan, itu akan terhubung ke Host dan mengambil rahasia, menggunakannya, dan kemudian Anda dapat mematikan jembatan Host. Bahkan jika build-args disimpan di suatu tempat, mereka menjadi tidak berguna saat server dimatikan.

Server mendukung Penerusan Agen SSH, disalurkan melalui komunikasi soket web TLS. Ia bekerja pada Windows juga!

Alexandre, apa yang Anda lakukan sangat kreatif dan terampil. Itu hanya
membuatku sedih bahwa perlu melompati semua langkah ini hanya untuk
mencapai hal yang sama seperti yang dapat dilakukan jika 'docker build' mendukung 'mount'
perintah daripada desakan buta bahwa semuanya disalin ke dalam
wadah.

Saya kasus saya, saya akan meninggalkan 'docker build' dan sebagai gantinya menggunakan rocker atau
sesuatu jika ciptaan saya sendiri.

Pada Kamis, 13 Juli 2017, 16:23 Alexandre Bourget, [email protected]
menulis:

FYI, saya menulis https://github.com/abourget/secrets-bridge untuk mengatasi
masalah rahasia waktu pembuatan.

Ini menciptakan konfigurasi sekali pakai yang dapat Anda berikan sebagai argumen,
selama proses pembuatan, itu akan terhubung ke host dan mengambil
rahasia, gunakan, dan kemudian Anda dapat membunuh jembatan host. Bahkan jika
build-args disimpan di suatu tempat, mereka menjadi tidak berguna saat server
dibunuh.

Server mendukung Penerusan Agen SSH, disalurkan melalui TLS
komunikasi soket web. Ia bekerja pada Windows juga!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/13490#issuecomment-315111388 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAZk5hZqTAgPBjS9cFP_IsYNa9wv-yoAks5sNjaBgaJpZM4Eq021
.

Ini adalah proposal rahasia terbaru: https://github.com/moby/moby/issues/33343

Saya pikir fungsionalitas "pembangunan multi-tahap" baru yang disertakan di dalam rilis Docker CE terakhir memecahkan sebagian besar masalah kami.

https://docs.docker.com/engine/userguide/eng-image/multistage-build/

Wadah yang muncul untuk menjalankan perintah dari Dockerfile datang dengan /dev dimasak dan tidak ada perubahan yang dilakukan di sana yang harus direkam ke dalam lapisan. Bisakah buruh pelabuhan mengirimkan rahasia pengguna melalui titik pemasangan itu? Cara serupa memberikan /dev/init ?

Ini masih cukup penting karena multistage build dengan argumen tidak bocor di gambar tetapi masih mengekspos rahasia Anda sebagai bagian dari daftar proses pada sistem yang sedang berjalan sehingga tidak benar-benar terpecahkan.

Ini Agustus 2017. Sementara itu "proposal lama untuk menangani rahasia" di edisi asli tertaut ke edisi 2014.

Masih belum ada solusi bagus untuk rahasia waktu pembuatan. PR yang menawarkan flag --build-time-secret ditutup tanpa penjelasan. Tidak ada yang disajikan dalam "Jadi, apa yang dibutuhkan?" bagian dilaksanakan.

Sementara itu

CEO Steve Singh yang baru dilantik berfokus pada pelanggan bisnis
Putaran terakhir $75 juta untuk membantu membentuk penjualan, tim pemasaran

UPD.: seperti yang ditunjukkan @cpuguy83 dengan benar dan tepat di bawah ini, ringkasan lengkap proposal ada di #33343

Saya tahu itu tidak ada di dalamnya, tetapi secrets-bridge bekerja dengan cukup baik untuk saat ini.

@dmitriid Saya memahami rasa frustrasi Anda karena fitur ini hilang. Namun ini bukan cara menangani komunitas open source (atau komunitas mana pun).

Saya memposting tautan ke proposal di atas, dan telah melihat persis 0 komentar di dalamnya kecuali milik saya sendiri.

Inilah proposal rahasia terbaru: #33343

@cpuguy83 Luar biasa! Saya agak melewatkan sepertiga terakhir dari diskusi ini (dan beberapa lainnya) karena banyak hal untuk dibaca (sementara pada saat yang sama mencari solusi), jadi saya sangat merindukan komentar Anda, maaf :(

Utas ini dimulai pada tahun 2015.

Ini tahun 2017.

Mengapa tidak ada solusi untuk rahasia waktu pembuatan yang tidak meretas dan mengerikan? Ini jelas merupakan masalah besar bagi banyak orang, tetapi masih belum ada solusi yang benar-benar bagus!

@mshappe

Mengapa tidak ada solusi untuk rahasia waktu pembuatan yang tidak meretas dan mengerikan?

Karena ini adalah masalah yang sulit untuk dipecahkan dengan benar dan itu adalah sesuatu yang akan digunakan oleh jutaan orang.

Silakan lihat komentar saya tepat di atas komentar Anda:

Saya memposting tautan ke proposal di atas, dan telah melihat persis 0 komentar di dalamnya kecuali milik saya sendiri.
Inilah proposal rahasia terbaru: #33343

Jika Anda ingin melihat sesuatu diimplementasikan maka Anda perlu melakukan lebih dari sekadar mengeluh bahwa ada sesuatu yang tidak diterapkan. Silahkan komentari proposalnya!

Ini sangat mudah untuk dipecahkan. Itu hanya membutuhkan sesuatu, apa pun yang tidak
dipanggang ke dalam gambar. Dan sebenarnya sangat mudah untuk menyelesaikannya, hentikan penggunaan
'docker build' dan gunakan python API, rocker, atau apa pun.

Pada hari Rabu, 23 Agustus 2017 jam 21:42, Brian Goff [email protected]
menulis:

@mshappe https://github.com/mshappe

Mengapa tidak ada solusi untuk rahasia waktu pembuatan yang tidak meretas dan
mengerikan, belum?

Karena itu adalah masalah yang sulit untuk dipecahkan dengan benar dan itu adalah sesuatu yang
akan digunakan oleh jutaan orang.

Silakan lihat komentar saya tepat di atas komentar Anda:

Saya memposting tautan ke proposal di atas, dan telah melihat persis 0 komentar di
itu kecuali milikku sendiri.
Inilah proposal rahasia terbaru: #33343
https://github.com/moby/moby/issues/33343

Jika Anda ingin melihat sesuatu diimplementasikan maka Anda harus melakukan lebih dari
mengeluh bahwa ada sesuatu yang tidak dilaksanakan. Silahkan komentari proposalnya!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/13490#issuecomment-324441280 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AAZk5oEpcipmfCji1mXz6MOVt0p6-OA6ks5sbIC0gaJpZM4Eq021
.

@binarytemple Saya sudah mulai melihat Rocker sebagai alternatif, sebenarnya ... tetapi hanya karena buruh pelabuhan blok mental yang aneh ini tampaknya memiliki rahasia waktu pembuatan.

Itu aneh. Saya berbicara dengan orang-orang dan mereka melakukan semua jenis peretasan bodoh
seperti menggunakan layanan HTTP - membuang semuanya (pemantauan/granular
izin/kesederhanaan) yang disediakan oleh kombo POSIX/SELinux. Aku hanya tidak
memahami. Penolakan itu menurut saya tidak logis.

Pada Rabu, 23 Agustus 2017, 23:03 Michael Scott Bentuk [email protected]
menulis:

@binarytemple https://github.com/binarytemple Saya sudah mulai melihat
Rocker sebagai alternatif, sebenarnya ... tapi hanya karena ini aneh
mental block docker tampaknya memiliki rahasia waktu pembuatan.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/13490#issuecomment-324461257 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAZk5ppZYsOhdfvgotCUk5l41Truo_EEks5sbJOLgaJpZM4Eq021
.

Pembangunan buruh pelabuhan multi-tahap memecahkan banyak masalah ini.

Dalam bentuknya yang paling sederhana, Anda dapat menyuntikkan rahasia sebagai build-args, dan itu hanya akan menjadi bagian dari riwayat gambar dari gambar yang secara eksplisit mengatakan bahwa mereka membutuhkan argumen. Seperti yang ditunjukkan oleh

Server build kami berjalan dengan beberapa rahasia yang dipasang sebagai volume, jadi salinan CI kami di f.ex. /mnt/secrets/.npmrc ke dalam direktori kerja saat ini. Kemudian kami menggunakan Dockerfile yang mirip dengan yang di bawah ini.

FROM node:latest
WORKDIR /usr/src/app
COPY .npmrc .
RUN echo '{ "dependencies": [ "lodash" ] }' > package.json
RUN npm install
RUN ls -lah

FROM alpine:latest
WORKDIR /usr/src/app
COPY --from=0 /usr/src/app/node_modules ./node_modules
RUN ls -lah
CMD ["ls", "./node_modules"]

Gambar yang dihasilkan akan memiliki dependensi yang diinstal, tetapi bukan .npmrc atau jejak kontennya.

Menggunakan build multi-tahap memberi Anda kontrol penuh tentang cara mengekspos rahasia waktu build ke proses build. Anda bisa mendapatkan rahasia dari toko eksternal seperti Vault, melalui volume (yang kami pasang dari toko Rahasia di Kubernetes), dengan mengenkripsi gpg di repositori, rahasia Travis, dll.

Saat menggunakan build multi-tahap untuk kasus penggunaan ini, pastikan Anda menyadari bahwa data rahasia akan tetap berada di dalam gambar yang tidak diberi tag di daemon lokal hingga gambar tersebut dihapus sehingga data ini dapat digunakan untuk cache build di build berikutnya. Tapi itu tidak didorong ke registri saat mendorong gambar yang diberi tag terakhir.

@androa Saya suka solusi itu tetapi saya tidak yakin bagaimana perasaan saya tentang rahasia yang disalin ke direktori kerja. Itu mungkin baik-baik saja di server CI pribadi, tetapi itu tidak terlalu bagus untuk bangunan lokal tempat Anda akan menyalin file yang tidak boleh keluar dari lokasi yang dilindungi (belum lagi bahwa penyalinan itu sendiri mengganggu dan berbahaya karena mungkin secara tidak sengaja berakhir di kontrol sumber). Opsi lainnya adalah menggunakan konteks build Docker yang lebih luas, tetapi untuk banyak rahasia umum yang dapat berarti seluruh volume root. Adakah saran tentang cara membuat ini bagus untuk lokal dan CI?

Ini mengerikan. "Platform wadah perangkat lunak terkemuka di dunia" yang diproklamirkan sendiri tidak dapat diganggu untuk meneruskan rahasia waktu pembuatan dengan aman ke dalam wadah selama 3 tahun terakhir sekarang.

Dengan pendekatan "kami lebih tahu" dan "jangan membuat perangkat lunak membiarkan kesalahan" dan apa yang paling baik digambarkan sebagai kelalaian yang tidak menguntungkan pada fase desain, tidak ada dukungan dan tidak ada kemajuan yang terlihat menuju salah satu fitur yang diperlukan perangkat lunak DevOps. Semua komunitas yang disarankan dan kadang-kadang bahkan dikembangkan ke titik perbaikan siap-gabung ditutup karena takut seseorang menyalahgunakannya. Sebagai akibat dari kegagalan cluster..., semua cara untuk melewatkan kunci pribadi yang diperlukan hanya untuk fase pembuatan wadah buruh pelabuhan memerlukan penyimpanan rahasia tersebut dalam riwayat pembangunan, atau terlihat dalam daftar proses dengan harapan bahwa, masing-masing, riwayat pembangunan tidak pernah meninggalkan mesin tepercaya atau tidak ada orang yang seharusnya tidak pernah melihat daftar proses. Keduanya akan gagal bahkan audit keamanan yang paling permisif.

Masalah ini terbuka selama lebih dari 2 tahun sekarang untuk meringkas apa yang diketahui tentang masalah itu dan apa yang harus dilakukan untuk mengatasinya. Masih belum ada solusi. Maksud saya bukan solusi komprehensif yang akan mendukung skema manajemen rahasia paling kompleks di luar kotak. Tidak ada solusi SAMA SEKALI, tidak ada variabel lingkungan host, tidak ada pemuatan rahasia dari jalur file di luar konteks build. Tidak ada yang bisa dianggap aman bahkan dalam istilah yang paling tidak ketat.

@OJezu Seperti yang telah saya nyatakan beberapa kali tentang masalah ini , ada proposal terbuka dengan pada dasarnya 0 komentar di atasnya.
Jika Anda ingin melihat rahasia didorong ke depan, silakan luangkan waktu untuk mengomentari proposal tersebut.

Alih-alih datang dengan senjata api yang berkobar menyerang orang-orang yang mengerjakan ini setiap hari, lain kali cobalah mengajukan pertanyaan dan membaca setidaknya komentar terbaru tentang masalah yang Anda komentari.

Hal-hal sering terlihat terhenti ketika benar-benar hanya ada orang yang bekerja keras.
Untuk membangun, lihat github.com/moby/buildkit di mana sebagian besar pekerjaan ini terjadi hari ini.

Terima kasih.

Saya agak mabuk, karena hari ini saya menghabiskan 9 jam mencoba mencari solusi untuk sesuatu yang seharusnya tidak menjadi masalah, terutama dalam proyek yang sedang dikerjakan secara penuh waktu dan memposisikan diri sebagai standar de facto dan jiwa yang masuk akal. . Saya berusaha sangat keras untuk tidak mengumpat dan berhenti menyakiti diri sendiri saat menulis komentar ini.

Saya melihat masalah itu, dan melihat referensi ke dua solusi, satu terhenti sejak April, yang lain sudah ditutup. Mau tidak mau saya memperhatikan, bahwa proposal 0 komentar memiliki 4 peserta, jumlah komentar yang sama, dan menyebutkan beberapa diskusi internal yang jelas, saya kira oleh orang-orang yang lebih akrab dengan seluk-beluk . Tetapi Jika Anda ingin umpan balik tambahan dari seseorang yang bahkan tidak memprogram, saya dapat memberikan lebih banyak pemikiran tentang masalah yang saya sentuh di komentar sebelumnya.

@OJezu

Setidaknya ada satu solusi mudah: gunakan layanan khusus (misalnya dijalankan di Jenkins) untuk membuat artefak.
Layanan itu akan disediakan dengan aman semua kunci yang diperlukan untuk mengakses artefak yang bergantung pada gambar Anda.
Artefak yang sudah selesai akan ditempatkan di lokasi yang aman (misalnya Jenkins). Artefak itu tidak akan mengandung rahasia apa pun, hanya direktori dengan binari/sumber/dll.
Kemudian layanan lain (misalnya pekerjaan Jenkins lainnya) akan mengakses artefak yang dibuat sebelumnya dan mengubahnya menjadi gambar yang dapat didorong dengan aman ke registri gambar, yang pada gilirannya dilindungi dengan aman menggunakan rbac/kunci untuk mengaksesnya dari mesin pengembang/produksi.

Yaitu proses pembuatan gambar buruh pelabuhan tidak berbeda dengan sistem pembangunan lain di luar sana: Anda harus memiliki pipa pembangunan di tempat.

@Vanuan tidak semua bahasa sesederhana itu dengan pengemasan dan pemasangan, cukup dengan menginstal dengan artefak.

Contohnya?

Proyek Python menarik persyaratan mereka pada waktu penginstalan, bukan pada waktu pembuatan. Dalam kasus kami, dari repositori pypi/conda pribadi (dilindungi kata sandi)

Jadi? Jadikan penginstalan sebagai bagian dari proses pembuatan Anda, lalu salin paket yang diinstal ke gambar baru.

Anda hanya perlu memastikan bahwa gambar build dan gambar produksi Anda didasarkan pada gambar dasar Python yang sama.

Anda memang bisa menyalin semuanya menjadi gambar baru. Itu menghilangkan inti dari Dockerfile. Mengapa memiliki Dockerfile jika satu-satunya hal yang dapat Anda gunakan hanyalah menyalin satu set direktori?

Jadi, saya tidak dapat memiliki aliran sederhana di mana saya hanya menjalankan docker build . mana pun - baik di mesin dev atau CI, tetapi saya harus bergantung pada CI untuk membangun paket. Mengapa repot-repot dengan buruh pelabuhan? Saya dapat menulis file travis, atau mengkonfigurasi aliran dalam bambu.

Tidak bisakah Anda hanya pip install requirements.txt di tahap pertama Anda membangun dengan rahasia yang tersedia untuk diambil dari repositori pribadi Anda. Kemudian tahap selanjutnya hanya menyalin paket situs dari tahap pertama.

Mengapa memiliki Dockerfile jika satu-satunya hal yang dapat Anda gunakan hanyalah menyalin satu set direktori?

Mengapa tidak? Menggunakan Dockerfile untuk membangun itu konsisten.

Spesifikasi gambar lebih dari sekadar sekumpulan file zip. Ada variabel lingkungan, argumen baris perintah, volume, dll

Baca referensi Dockerfile:
https://docs.docker.com/engine/reference/builder/

Sepertinya Anda lebih fokus pada instruksi RUN , berpikir bahwa Dockerfile adalah pengganti Makefile Anda. Bukan itu. Dockerfile dimaksudkan untuk satu hal saja: membangun gambar dari beberapa bahan sumber. Apa materi sumber itu - biner yang diunduh melalui http atau repositori git - tidak masalah. Docker tidak perlu menjadi sistem CI Anda, meskipun Anda dapat menggunakannya sebagai sistem dalam kondisi tertentu.

Saya dapat menulis file travis, atau mengkonfigurasi aliran dalam bambu.

Jika Anda bisa mendapatkan hasil dari proses build Anda dan kemudian menjalankannya di lingkungan lain, tanpa gambar dan wadah, maka Anda pasti tidak perlu repot dengan buruh pelabuhan. Mengapa kamu akan?

Terpisah, lingkungan yang dikontrol secara ketat yang mendapat jaminan reset di antara build, tetapi hanya jika langkah build telah berubah. Kemampuan untuk menjalankannya di mana saja, tidak hanya di server CI (seperti dengan Travis), mengikat instruksi build dengan kode, yang menurut saya bagus jika build berubah untuk cabang kode yang berbeda (misalnya mengubah versi lingkungan yang dijalankan hanya pada satu cabang). Kemungkinan untuk menjalankan wadah build pada mesin pengembang, memungkinkan pengiriman seluruh lingkungan ke pengembang yang sebaliknya tidak tahu cara memutakhirkan sistem mereka sendiri, tetapi akan dapat membangun aplikasi dengan perubahan mereka secara lokal dengan lingkungan yang sama seperti orang lain.

Jika saya tidak menginginkan semua itu, saya akan tetap menggunakan lxc + ansible, tidak perlu buruh pelabuhan.

Anda tidak perlu docker build untuk itu.

Anda tidak perlu docker build untuk itu.

Tentu saja Anda juga dapat menyediakan skrip Makefile atau build_image.sh untuk setiap proyek alih-alih satu Dockerfile mandiri, tetapi itu memiliki banyak kelemahan:

• Kompatibilitas lintas platform: Dengan menyediakan Dockerfile, saya tahu bahwa sistem apa pun yang dapat menjalankan docker build akan dapat membangun image. Dengan menyediakan Makefile atau build_image.sh , saya harus memastikan secara manual bahwa itu berfungsi di semua platform yang ingin saya dukung.
• Antarmuka yang dikenal untuk pengguna: Jika Anda mengenal buruh pelabuhan, Anda mengetahui beberapa perilaku docker build untuk proyek apa pun, bahkan tanpa melihat Dockerfile (mis. sehubungan dengan caching, dll...). Jika saya memiliki kustom Makefile atau build_image.sh , untuk setiap proyek, saya harus terlebih dahulu mencari tahu apa perintah untuk membangun, membersihkan, di mana dan dalam bentuk apa hasilnya, jika ada adalah beberapa caching dan dalam bentuk apa, ...

Oh, Dockerfile jauh dari mandiri. Terutama untuk lingkungan pembangunan.
Pertimbangkan ini:

• kebanyakan pengembang tidak tahu semua opsi berbeda dari docker build , tetapi hampir semua orang tahu cara menjalankan skrip bash
• docker build tergantung pada direktori konteks . Jadi, kecuali jika Anda bersedia menunggu gigabyte data (kode sumber Anda dengan dependensi) untuk berpindah dari satu lokasi ke lokasi lain untuk setiap perubahan baris sumber, Anda tidak akan menggunakannya untuk pengembangan.
• kecuali Anda membangun SEMUA dari awal, Anda memiliki ketergantungan pada registri buruh pelabuhan
• kemungkinan Anda akan bergantung pada repositori OS (apakah Anda menggunakan gambar berbasis Debian atau Alpine), kecuali jika Anda mem-boot wadah langsung ke biner yang dibuat secara statis
• kecuali jika Anda melakukan semuanya ke git, Anda akan memiliki beberapa dependensi tingkat proyek, baik itu npm, indeks paket python, rubygems, atau apa pun. Jadi, Anda akan bergantung pada beberapa registri paket eksternal atau cerminnya
• seperti yang diperhatikan kebanyakan orang di sini, Anda akan bergantung pada beberapa lokasi paket rahasia untuk dependensi pribadi Anda yang tidak dapat Anda publikasikan ke repositori publik, jadi Anda akan bergantung padanya
• penyediaan rahasia diperlukan untuk mengakses lokasi aman itu, jadi Anda akan bergantung pada beberapa sistem yang akan mendistribusikan rahasia ke pengembang
• selain Dockefile, Anda memerlukan docker-compose.yml, dan itu bukan lintas platform: Anda masih bergantung pada perbedaan forward-/backslash .

Kompatibilitas lintas platform: Dengan menyediakan Dockerfile, saya tahu bahwa sistem apa pun yang dapat menjalankan docker build akan dapat membangun image.

Dockerfile tidak memastikan kompatibilitas lintas platform. Anda masih harus menyediakan banyak file Docker untuk beberapa platform. "Dapat menjalankan docker build" tidak berarti "Menggunakan Linux" lagi. Docker juga mendukung gambar asli Windows. Anda masih harus menggunakan Cygwin + Linux VM jika Anda ingin menjalankan sesuatu yang secara khusus ditargetkan untuk mesin Linux pada host Windows.

Oh, dan saya bahkan tidak menyebutkan x86 vs ARM...

Antarmuka yang dikenal untuk pengguna: Jika Anda mengenal buruh pelabuhan, Anda mengetahui beberapa perilaku pembangunan buruh pelabuhan untuk proyek apa pun, bahkan tanpa melihat Dockerfile

Kecuali Anda tidak melakukannya. Semua orang tahu cara menjalankan skrip bash tanpa parameter atau satu perintah make . Hanya sedikit orang yang tahu cara menentukan dengan benar semua opsi baris perintah yang berbeda untuk docker build , docker run atau docker-compose . Tidak dapat dihindari bahwa Anda akan memiliki beberapa skrip bash atau cmd pembungkus.

Dengan segala hormat atas apa yang dilakukan orang-orang Docker, saya pikir Anda meminta terlalu banyak. Saya khawatir proyek Moby tidak memiliki cakupan yang begitu luas untuk mendukung semua alur kerja pengembangan yang dapat dibayangkan.

Saya tidak akan menyangkal semua poin Anda satu per satu. Pertama, Anda tentu saja selalu dapat menemukan situasi di mana pendekatan "single Dockerfile" tidak berfungsi sama sekali. Namun, saya berpendapat, bahwa untuk hampir semua poin Anda yang Anda kemukakan (yang semuanya valid dan relevan), pendekatan "skrip khusus atau makefile" sama buruknya atau lebih buruknya. Hanya sebagai contoh satu poin:

sebagian besar pengembang tidak mengetahui semua opsi berbeda dari build buruh pelabuhan, tetapi hampir semua orang tahu cara menjalankan skrip bash

Jika saya terlibat dalam 10 proyek, dan semuanya menggunakan Dockerfile, saya perlu belajar tentang buruh pelabuhan hanya sekali, tetapi dengan saran Anda, saya perlu mempelajari 10 skrip build yang sama sekali berbeda. Bagaimana cara menghapus cache dan memulai dari awal untuk proyek Foo build_image.sh lagi? Itu tidak jelas. Jika membangun gambar dilakukan dengan docker build , itu jelas (ofc saya perlu tahu cara kerja buruh pelabuhan, tetapi saya juga perlu melakukannya untuk menggunakan gambar yang keluar dari build_image.sh ).

Secara keseluruhan, saya kira poin yang saya dan orang lain coba buat adalah bahwa untuk /many/ skenario pendekatan "single Dockerfile" tampaknya bekerja dengan sangat baik untuk orang-orang (yang merupakan alasan mengapa buruh pelabuhan menjadi begitu populer), khususnya di dunia open source di mana biasanya semua sumber daya dapat diakses tanpa rahasia. Tetapi jika Anda mencoba menerapkan pola yang sama yang Anda sukai dalam konteks di mana bagian dari sumber daya Anda memerlukan kredensial untuk diakses, pendekatannya rusak. Ada sejumlah saran (dan implementasi) dari cara teknologi yang tidak terlalu rumit untuk membuatnya bekerja, tetapi tidak ada yang berhasil dalam waktu yang lama (ini telah diletakkan berkali-kali di atas). Oleh karena itu frustrasi.

Saya menghargai bahwa orang-orang berupaya dalam hal ini, misalnya dengan proposal tertaut di #33343. Postingan saya adalah tentang memotivasi apa yang beberapa orang lakukan dan mengapa mereka terus kembali memintanya di sini.

Dengan segala hormat atas apa yang dilakukan orang-orang Docker, saya pikir Anda meminta terlalu banyak. Saya khawatir proyek Moby tidak memiliki cakupan yang begitu luas untuk mendukung semua alur kerja pengembangan yang dapat dibayangkan.

Tampaknya bagi saya bahwa apa yang kebanyakan orang minta di sini bukanlah hal semacam itu, tetapi hanya untuk cara sederhana menggunakan rahasia di docker build dengan cara yang tidak kalah aman daripada menggunakannya di build_image.sh kustom Anda

Maaf, tetapi setiap orang dalam tiket ini memiliki kasus penggunaan yang sedikit berbeda. Itu adalah kasus sudut dan membutuhkan solusi yang berbeda.

1. Saya ingin menjalankan gambar produksi pada mesin pengembangan. Gunakan registri buruh pelabuhan
2. Saya ingin sistem CI terdistribusi, sehingga setiap pengembang memiliki build yang dapat direproduksi. Gunakan docker run untuk membangun proyek Anda, gunakan docker prune untuk membersihkan
3. Saya ingin membuat gambar buruh pelabuhan sehingga saya dapat mendistribusikannya. Gunakan server CI khusus tempat Anda dapat menjalankan build multistage.

@Vanuan , jadi saya kira pendekatan Anda pada dasarnya adalah: jangan gunakan docker build, untuk apa pun selain lingkungan dasar. Ini adalah masalah yang dibuat untuk mengubah itu. "Anda harus melakukannya secara berbeda" ADALAH masalahnya, bukan solusinya.

Orang yang mendorong masalah ingin memiliki pendekatan yang lebih sederhana dan lebih mudah dengan gambar buruh pelabuhan, tidak harus meretas batasan buruh pelabuhan.

Bagi siapa pun yang tertarik: Saya telah mencoba mengeksploitasi argumen build "masked-by-default" seperti FTP_PROXY untuk membangun konteks. Aman sehubungan dengan fakta bahwa docker-build tidak mengekspos argumen bertopeng tersebut ke metadata gambar atau lapisan gambar.

36443 adalah upaya untuk mengembangkannya ke build-arg bernama seperti SECRET sehingga kami dapat mendorong pengguna untuk menggunakannya sebagai solusi sederhana untuk masalah manajemen rahasia.

Namun, pekerjaan tersebut telah ditolak secara wajar, karena sifat tertutup dari argumen build tersebut tidak dijamin di masa mendatang.

Taruhan terbaik saya setelah itu adalah mengikuti saran @AkihiroSuda , gunakan docker build --network atau alat seperti habitus untuk menyimpan/meneruskan rahasia melalui server tcp sementara hanya konteks build yang terlihat langsung dalam daemon docker tunggal, paling luas.

Mengomentari sebagian, jadi saya mendapat pemberitahuan 5 tahun dari sekarang, ketika Docker akhirnya memutuskan untuk memberi kami langkah kecil ke arah manajemen kredensial yang tepat.... dan juga, untuk memberikan garis besar peretasan yang saya gunakan saat ini , untuk membantu orang lain, atau untuk membuat lubang yang tidak saya sadari.

Dalam mengikuti masalah @mumoshu , saya akhirnya mendapat petunjuk untuk menggunakan argumen yang telah ditentukan untuk membangun rahasia.

Jadi, pada dasarnya, saya bisa menggunakan docker-compose, dengan pemetaan seperti ini:

  myProject:
    build:
      context: ../myProject/
      args: 
        - HTTPS_PROXY=${NEXUS_USERNAME}
        - NO_PROXY=${NEXUS_PASSWORD}

Dan kemudian, dalam folder dengan file docker-compose.yml, buat file bernama ".env" dengan pasangan nilai kunci NEXUS_USERNAME dan NEXUS_PASSWORD - dan nilai yang sesuai di sana.

Akhirnya, di Dockerfile itu sendiri, kami menentukan perintah run kami seperti ini:
JALANKAN wget --user $HTTPS_PROXY --password $NO_PROXY

Dan JANGAN mendeklarasikannya sebagai ARG di DockerFile.

Saya belum menemukan kredensial saya mengambang di build yang dihasilkan di mana pun ... tetapi saya tidak tahu apakah saya mencari di mana-mana..... Dan untuk pengembang lainnya di proyek saya, mereka masing-masing harus buat file .env dengan nilai yang sesuai untuknya.

@darmbrust Saya mencoba solusi Anda tetapi tidak berhasil.
Ini yml penulisan saya:
versi: "3.3"
jasa:

  buildToolsImage:
    image: vsbuildtools2017:web-v6

    build:
      context: .
      dockerfile: ./vsbuild-web-v6-optimized.dockerfile
      args:
        - CONTAINER_USER_PWD=${CONTAINER_USER_CREDS}

Ini file .env yang ada di sebelah file yml:

CONTAINER_USER_CREDS=secretpassword

Dan, inilah file docker saya:

# escape=`
FROM microsoft/dotnet-framework:4.7.2-sdk
# Add non-root user
CMD ["sh", "-c", "echo ${CONTAINER_USER_PWD}"] 
RUN net user userone ${CONTAINER_USER_PWD} /add /Y

Dan akhirnya perintah untuk memulai ini adalah seperti ini:

docker-compose -f docker-compose.buildImage.yml build

Itu membangun gambar tetapi tanpa menggunakan kata sandi yang disimpan dalam file .env.

[Peringatan] Satu atau lebih build-args [CONTAINER_USER_PWD] tidak digunakan

Apa yang kulewatkan di sini?
Terima kasih!

Anda harus menggunakan salah satu dari https://docs.docker.com/engine/reference/builder/#predefined -args dalam file buruh pelabuhan. Anda tidak dapat menggunakan nama argumen Anda sendiri seperti CONTAINER_USER_PWD.

Begitulah cara kerja triknya, karena buruh pelabuhan memiliki perilaku khusus untuk argumen yang telah ditentukan sebelumnya, di mana Anda dapat menggunakannya tanpa mendeklarasikannya. Dan dengan menggunakannya tanpa mendeklarasikannya, mereka tampaknya tidak dicatat di mana pun.

Dengan file docker-compose, Anda dapat memetakan argumen yang telah ditentukan sebelumnya ke sesuatu yang lebih masuk akal.

@darmbrust Ya, itu berhasil.
Namun, tidakkah menurut Anda baunya? Ada rekomendasi yang lebih baik?
Terima kasih!

Ini mungkin tidak berbau seperti mengekspos kredensial ssh-agent Anda melalui tcp
melalui socat untuk proses lokal apa pun untuk mencuri, tetapi memang, seperti apa pun
terkait dengan rahasia, 'docker build' memang cukup bau.

Sebenarnya, saya lupa bahwa Docker untuk Mac tidak dapat mengekspos domain Unix
soket pada host osx ke wadah, sehingga membuka lebih banyak lagi
sekaleng cacing.

Solusi saya saat ini, jalankan Centos VM, akun pengguna mesin GitHub
kredensial masuk ke dalamnya, buat menggunakan alat "Rocker" (usang).

Pada Kamis, 26 Juli 2018, 21:49 Sameer Kumar, [email protected] menulis:

@darmbrust https://github.com/darmbrust Ya, itu berhasil.
Namun, tidakkah menurut Anda baunya? Ada rekomendasi yang lebih baik?
Terima kasih!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/13490#issuecomment-408230125 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAZk5iz1kvCpZ0s65ng4TwL7LmHa9zZvks5uKitDgaJpZM4Eq021
.

Seluruh bug ini bau. Saya belum menemukan cara yang lebih baik... ada beberapa pendekatan lain di atas, tetapi saya pikir semua pendekatan aman lainnya memerlukan server http kecil untuk memasukkan informasi ke dalam gambar. mungkin kurang berbau, tetapi lebih rumit, lebih banyak alat, lebih banyak bagian yang bergerak.

Tidak yakin ada yang menemukan solusi "baik"... kita semua terjebak menunggu pekerja buruh pelabuhan untuk melakukan sesuatu tentangnya... jangan menahan napas, karena bug ini ditulis pada tahun 2015, dan mereka belum' t bahkan mengusulkan peta jalan, apalagi solusi.

Ini sangat sederhana dan jelas, memungkinkan pemasangan volume, (file atau
direktori) ke dalam wadah selama pembuatan.

Ini bukan batasan teknis, ini adalah keputusan untuk tidak membiarkan rahasia masuk
untuk mempertahankan perilaku - periksa, jalankan build, input yang sama, sama
output, ubah argumen build jika Anda ingin membatalkan cache ...

Masalahnya, abstraksinya semakin bocor
dengan orang-orang yang menggunakan segala macam peretasan yang tidak pasti dan tidak aman untuk mendapatkan "rahasia"
ke dalam sebuah wadah.

Newsflash, mengekspos keyring SSH Anda melalui TCP, bahkan di localhost tidak
aman, juga tidak meneruskan kredensial melalui variabel lingkungan (petunjuk, jalankan
ps, atau mengintip di sistem file /proc), argumen perintah, dan variabel lingkungan semuanya ada di sana, telanjang, untuk dilihat dunia.

Untuk pengembang kode golang, ini secara tradisional tidak menjadi masalah karena mereka menyalin dan menempel
ketergantungan mereka ke dalam proyek mereka daripada menggunakan alat manajemen ketergantungan, pengembang golang menyebut praktik ini, 'vendor'.

Untuk siapa saja yang bekerja di ekosistem lain di mana membangun sistem
mengambil dependensi dari Git, atau repositori yang memerlukan otentikasi, itu masalah besar.

Saya cukup yakin ada beberapa aturan startup di suatu tempat di sepanjang baris,
"jangan anggap Anda tahu, bagaimana, atau mengapa, pengguna Anda menggunakan produk".

Pada Kamis, 26 Juli 2018, 22:00 Dan Armbrust, [email protected] menulis:

Seluruh bug ini bau. Saya belum menemukan cara yang lebih baik ... ada
beberapa pendekatan lain di atas, tetapi saya pikir semua yang lain aman
perlu berdiri sedikit server http untuk memasukkan informasi ke dalam
gambar. mungkin kurang berbau, tetapi lebih rumit, lebih banyak alat, lebih bergerak
bagian.

Tidak yakin ada yang menemukan solusi "baik"... kita semua terjebak
menunggu orang-orang buruh pelabuhan untuk melakukan sesuatu tentang hal itu ... jangan pegang
nafas, karena bug ini ditulis pada tahun 2015, dan mereka bahkan belum melamar
sebuah peta jalan, apalagi solusi.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/13490#issuecomment-408233258 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAZk5nvbBTj4BAv5TtELNIHhJN8mU0Ctks5uKi38gaJpZM4Eq021
.

@binarytemple Semua orang yang pernah bekerja di Docker/moby (seperti pada insinyur di belakangnya) tahu persis apa masalahnya dan bahkan pernah menghadapinya.

Volumes adalah solusi yang sangat bocor.
Ada proposal, disebutkan sedikit aliran komentar, yang mencoba menyelesaikan ini dengan cara yang masuk akal (https://github.com/moby/moby/issues/33343)

Hal utama di sini adalah memberikan abstraksi yang "benar" daripada "abstraksi apa pun yang berhasil"... tentu saja kita tahu ini menyakitkan bagi banyak orang di lebih dari sekadar kasus ini.

Banyak pekerjaan yang telah dilakukan pada pembangun akhir-akhir ini yang belum tentu terlihat, tetapi buah dari upaya ini akan mulai terlihat dalam beberapa bulan mendatang.
Untuk memulainya, Docker 18.06 dikirimkan dengan implementasi builder alternatif yang didukung oleh https://github.com/moby/buildkit.
Anda mungkin berpikir "bagaimana ini membantu saya?". Buildkit menyediakan banyak primitif tingkat rendah yang memungkinkan kita menjadi jauh lebih fleksibel dalam pembangun Docker. Bahkan untuk dapat menyediakan parser build Anda sendiri (yang dapat berupa apa saja dari parser Dockerfile yang disempurnakan hingga sesuatu yang sama sekali berbeda). Parser ditentukan di bagian atas "Dockerfile" dan hanya gambar apa pun yang ingin Anda gunakan untuk mengurai file.

Jika Anda benar-benar ingin melihat sesuatu sekarang, Anda dapat mengambil buildkit itu sendiri dan menjalankannya hari ini, ia berada di atas containerd, Anda dapat membangun integrasi khusus dengan cukup cepat.

Dukungan pemasangan rahasia telah ditambahkan ke buildkit di https://github.com/moby/buildkit/pull/522 . Mereka muncul secara ketat di tmpfs, dikecualikan dari cache build dan dapat menggunakan sumber data yang dapat dikonfigurasi. Belum ada PR yang mengeksposnya dalam sintaks dockerfile tetapi harus menjadi tambahan sederhana.

Ada 2 solusi untuk membangun gambar dengan rahasia.

Membangun multi-tahap:

FROM ubuntu as intermediate
ARG USERNAME
ARG PASSWORD
RUN git clone https://${USERNAME}:${PASSWORD}@github.com/username/repository.git

FROM ubuntu
# copy the repository form the previous image
COPY --from=intermediate /your-repo /srv/your-repo

Kemudian : docker build --build-arg USERNAME=username --build-arg PASSWORD=password my-image .

Menggunakan pembuat gambar : docker-build-with-secrets

@BenoitNorrin maaf, tetapi Anda telah mengekspos kata sandi itu ke setiap proses di sistem Host. Keamanan Unix 101 - jangan letakkan rahasia sebagai argumen perintah.

Ya, tetapi ada beberapa penggunaan di mana keamanan sedikit kurang penting:

• Anda ingin membangun di komputer Anda sendiri
• Anda membangun server CI perusahaan Anda (seperti jenkins). Sebagian besar waktu ini tentang memiliki akses ke repositori pribadi (nexus, git, npm, dll), jadi CI Anda mungkin memiliki kredensialnya sendiri untuk itu.
• anda dapat menggunakan VM yang dibuat dari mesin buruh pelabuhan dan menghapusnya setelahnya.

Jika itu satu-satunya masalah, @binarytemple , maka cukup menambahkan flag docker image build --args-file ./my-secret-file seharusnya menjadi perbaikan yang cukup mudah untuk seluruh masalah ini, bukan? :pemikiran:

@yajo bisa, ya itu setidaknya solusi sampai buildkit dikirimkan dengan secret mount. Saran yang bagus. Terima kasih. B

Sayangnya sebagian besar solusi yang disebutkan dalam ini dan banyak tiket lainnya masih mengekspos rahasia ke gambar yang dihasilkan, atau hanya berfungsi dengan bahasa tertentu di mana Anda hanya memerlukan dependensi selama waktu kompilasi dan bukan selama instalasi.

@binarytemple yang tidak akan pernah terjadi, pengelola buruh pelabuhan telah membunuh setidaknya satu PR yang didokumentasikan sepenuhnya dan sepenuhnya diimplementasikan dari fitur rahasia yang aman. Mengingat sisa sejarah (tiket berusia 3 tahun ini bukan yang tertua dan jelas bukan satu-satunya tiket/PR tentang topik ini) saya pikir aman untuk mengatakan pengelola buruh pelabuhan tidak memahami kebutuhan akan keamanan, yang merupakan masalah besar masalah.

Titik rasa sakit terbesar adalah rotasi rahasia untukku

Anda harus mempertahankan grafik rahasia untuk dependensi layanan, dan memperbarui dua kali setiap layanan (untuk kembali ke nama rahasia asli)

daftar rahasia dari layanan tampaknya tidak mudah (saya menyerah setelah beberapa upaya sekitar docker service inspect --format='{{.Spec.TaskTemplate.ContainerSpec.Secrets}}' <some_service> ), daftar dependensi layanan dari docker secret inspect <secret_name> akan berguna juga. Jadi saya hanya mempertahankan grafik (perkiraan) itu secara manual untuk saat ini.

Anda juga harus menentukan tujuan rahasia, ketika itu bukan /run/secrets/<secret_name> default dalam perintah pembaruan layanan buruh pelabuhan

Saya hanya berharap cara yang lebih sederhana untuk memutar rahasia

@caub inilah beberapa bantuan CLI:

Dokumen Docker untuk bantuan

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName}}{{end}}'

Itu akan mencantumkan semua nama rahasia dalam suatu layanan. Jika Anda menginginkan nama dan ID, Anda dapat:

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName .SecretID}}{{end}}' nginx

Saya selalu memiliki CI/CD (perintah pembaruan layanan) atau menumpuk file hardcode path sehingga Anda tidak memiliki masalah rotasi.

Dengan label, Anda dapat membuat otomatisasi CI/CD mengidentifikasi rahasia yang tepat jika Anda tidak menggunakan file tumpukan (tanpa memerlukan nama rahasia, yang akan berbeda setiap waktu).

docker build --secret akhirnya tersedia di Docker 18.09 https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

@thaJeztah Apakah kita siap untuk menutup masalah ini?

Untuk versi docker yang lebih lama, menggunakan multistage build dengan menyalin rahasia sebelum perintah build adalah opsi yang layak, bukan?

```
DARI debian sebagai build
SALIN ./secret.conf /path/on/image/
RUN build.sh
...

DARI debian
SALIN --dari=membangun ...

@andriy-f ya, itu berhasil, selama Anda;

• (jelas) jangan salin rahasia ke tahap akhir , atau:
• gunakan build stage / stage di mana sebuah rahasia hadir sebagai "induk" untuk gambar akhir
• jangan pernah _push_ tahap pembuatan ke registri
• percayai host tempat daemon Anda berjalan; yaitu dengan mempertimbangkan bahwa tahap "build" Anda dipertahankan sebagai gambar; seseorang dengan akses ke gambar itu akan bisa mendapatkan akses ke rahasia Anda.

rahasia waktu pembuatan sekarang dimungkinkan saat menggunakan buildkit sebagai pembuat; lihat posting blog di sini https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

dan dokumentasinya; https://docs.docker.com/develop/develop-images/build_enhancements/

opsi RUN --mount digunakan untuk rahasia akan segera beralih ke sintaks Dockerfile default (stabil)

Terima kasih @thaJeztah Saya melakukan sedikit penggalian lagi dan menemukan artikel itu tidak lama setelah memposting (postingan sebelumnya sekarang dihapus). Terima kasih lagi!

Dingin. Itu menutup pertanyaan rahasia waktu pembuatan. Apa saja untuk runtime/devtime (ssh di OS X)?