Menggunakan Dockerfile, selalu sulit untuk mengakses sumber daya pribadi. Tidak ada solusi yang baik. Tidak baik menggunakan variabel lingkungan atau hanya menghapus file rahasia setelah digunakan: mereka tetap dalam metadata gambar. Pengguna kadang-kadang pergi ke trik: mereka membuat majelis multi-tahap, namun, sangat hati-hati harus diambil sehingga tidak ada nilai rahasia pada tahap akhir, dan file rahasia disimpan dalam cache perakitan lokal hingga kliping.
Tim pembuat Docker 18 September menyertakan banyak pembaruan. Fitur utamanya adalah versi implementasi server sisi yang sepenuhnya baru telah muncul, ditawarkan sebagai bagian dari proyek Moby BuildKit. Aplikasi server BuildKit telah memperoleh fitur-fitur baru, termasuk dukungan untuk rahasia build Dockerfile.
Menggunakan Rahasia
Pertama-tama, Anda harus mengaktifkan sisi server BuildKit. BuildKit dalam versi 18.09 adalah fungsi seleksi yang dapat diaktifkan menggunakan DOCKER_BUILDKIT=1 variabel lingkungan sebelum meluncurkan docker build . Dalam versi berikutnya, direncanakan untuk membuat BuildKit bagian server secara default.
export DOCKER_BUILDKIT=1
Menerapkan rahasia pembuatan didasarkan pada dua fitur BuildKit baru. Salah satunya adalah kemampuan untuk menggunakan antarmuka pengguna yang diambil dari gambar dalam registri; yang kedua adalah kemampuan untuk menggunakan titik pemasangan pada perintah RUN untuk Dockerfile. Untuk menggunakan fungsi implementasi yang mendukung rahasia (alih-alih yang standar), tentukan gambar penghubung menggunakan arahan sintaks di baris pertama Dockerfile - menunjukkan gambar wadah yang ingin Anda gunakan. Sejauh ini, rahasia di saluran stabil Dockerfiles eksternal tidak tersedia: Anda akan memerlukan salah satu versi di saluran eksperimental, misalnya, docker/dockerfile:experimental atau docker/dockerfile/1.0.0-experimental .
# syntax=docker/dockerfile:1.0.0-experimental
Jika Anda, sebagai penulis Dockerfile, tahu bahwa perintah RUN dipasang di Dockerfile membutuhkan nilai rahasia, gunakan label --mount untuk itu, yang menunjukkan rahasia yang dibutuhkan perintah dan di mana harus memasangnya. Label --mount menerima struktur yang dipisahkan koma sebagai dalam --mount untuk docker run .
# syntax=docker/dockerfile:1.0.0-experimental FROM alpine RUN --mount=type=secret,id=mysite.key command-to-run
Label ini menunjukkan bahwa selama operasi perintah memiliki akses ke file rahasia di sepanjang jalur / /run/secrets/mysite.key . Rahasianya hanya tersedia untuk tim dengan label pemasangan, dan tidak untuk bagian lain dari majelis. Data dalam file ini diunduh dari toko rahasia berdasarkan pada pengidentifikasi yang ditentukan "mysite.key". Antarmuka baris perintah Docker saat ini mendukung pengungkapan rahasia dari file klien lokal menggunakan tag --secret .
docker build --secret id=mysite.key,src=path/to/mysite.key .
Seperti dijelaskan di atas, rahasia ditetapkan secara default di /run/secrets , namun, Anda dapat menentukan jalur apa pun menggunakan kunci "target". Jika "target" ditentukan, tetapi "id" tidak, maka "id" secara default menjadi nama dasar dari jalur tujuan.
Tidak perlu dibatasi pada satu rahasia. Anda dapat menggunakan nomor apa saja, yang menunjukkan pengidentifikasi yang berbeda.
Jika penulis Dockerfile menunjukkan bahwa instruksi RUN dapat menggunakan rahasia, dan pengguna yang memanggil majelis tidak menyediakannya, maka rahasianya diabaikan dan tidak ada file yang diinstal pada jalur yang ditentukan. Jika situasi ini tidak diinginkan, gunakan kunci "wajib": ini akan menunjukkan bahwa tanpa nilai perakitan akan gagal.
# syntax=docker/dockerfile:1.0.0-experimental FROM alpine RUN --mount=type=secret,id=mysite.key,required <command-to-run>
Implementasi
File rahasia secara otomatis diinstal hanya dalam sistem file tmpfs terpisah untuk mencegah kebocoran pada gambar akhir atau perintah berikutnya, dan sehingga tidak disimpan dalam cache build lokal.
Nilai-nilai rahasia juga dikecualikan dari membangun penghitungan cache sehingga cache metadata tidak dapat digunakan.
Ssh
Paling sering, mereka mungkin mencoba mengakses repositori pribadi melalui protokol SSH. Ya, Anda dapat menggunakan elemen rahasia untuk mengungkapkan kunci pribadi SSH untuk perakitan, tetapi ada solusi yang lebih baik. Protokol SSH menggunakan kriptografi kunci publik, dan berkat desain ini, Anda tidak perlu mengungkapkan kunci pribadi Anda kepada siapa pun. Misalnya, jika Anda menggunakan beberapa komputer dengan SSH, Anda tidak perlu mentransfer kunci Anda - cukup sediakan koneksi melalui protokol ssh-A .
Kami menambahkan fitur serupa di docker build , di mana Anda dapat menggunakan label --ssh untuk mengarahkan koneksi agen SSH yang ada atau kunci ke linker. Alih-alih mengirimkan informasi utama, Docker hanya memberi tahu tautan bahwa itu tersedia. Jika tautan perlu mengakses server jarak jauh melalui SSH, ia akan menghubungi klien dan meminta konfirmasi permintaan spesifik yang diperlukan untuk koneksi. Kuncinya sendiri tidak meninggalkan program klien, dan setelah menyelesaikan program yang membutuhkan akses, tidak ada data yang tersisa dari tautan untuk menyambung kembali koneksi jarak jauh.
Akses ke transfer file melalui protokol SSH hanya diberikan untuk perintah di Dockerfile yang secara langsung meminta akses ke SSH dengan menentukan blok type=ssh . Perintah lain tidak memiliki data pada agen SSH yang tersedia.
Perlu juga dicatat aspek lain dari SSH - penggunaan model keamanan TOFU. Saat menyambungkan ke server SSH untuk pertama kalinya, ia akan meminta informasi tentang host yang tidak dikenal, karena ia tidak memiliki kunci publik yang tersedia secara lokal untuk server ini dan, karenanya, tidak dapat memeriksa apakah kunci publik yang disediakan oleh pihak jarak jauh valid untuk alamat ini.
Ketika merakit dengan Dockerfile, kebenaran permintaan ini tidak dapat diverifikasi, dan karenanya, kunci publik dari server harus sudah ada dalam wadah yang mencoba menggunakan SSH. Ada beberapa cara untuk mendapatkan kunci publik ini. Misalnya, gambar dasar akan menyediakannya, atau Anda akan menyalinnya dari konteks pembuatan. Jika Anda menginginkan solusi yang lebih sederhana, jalankan program ssh–keyscan sebagai bagian dari rakitan - ini akan memuat kunci publik host saat ini.
Untuk meminta akses SSH ke perintah RUN di Dockerfile, Anda harus menentukan blok jenis "ssh". Kemudian, selama proses berlangsung, soket akan dipasang dengan akses hanya baca ke agen SSH. Ini juga akan mengatur variabel lingkungan SSH_AUTH_SOCK sehingga program yang menggunakan protokol SSH secara otomatis menggunakan soket ini.
# syntax=docker/dockerfile:experimental FROM alpine # install ssh client and git RUN apk add --no-cache openssh-client git # download public key for github.com RUN mkdir -p -m 0600 ~/.ssh && ssh-keyscan github.com >> ~/.ssh/known_hosts # clone our private repository RUN --mount=type=ssh git clone git@github.com:myorg/myproject.git myproject
Di sisi klien Docker, gunakan label --ssh menunjukkan bahwa penerusan SSH diperbolehkan untuk unit ini.
docker build --ssh default .
Label menerima sepasang nilai kunci yang menentukan lokasi soket agen SSH lokal atau kunci pribadi. Jika Anda ingin menggunakan nilai default=$SSH_AUTH_SOCK , Anda dapat membiarkan jalur soket kosong.
Di blok Dockerfile, Anda juga dapat menggunakan kunci id untuk memisahkan berbagai server dalam rakitan yang sama. Misalnya, akses ke berbagai repositori di Dockerfile dapat diperoleh dengan kunci penggunaan yang berbeda. Dalam hal ini, di Dockerfile Anda akan menggunakan:
… RUN --mount=type=ssh,id=projecta git clone projecta … RUN --mount=type=ssh,id=projectb git clone projectb …
dan perluas data klien dengan docker build --ssh projecta=./projecta.pem --ssh projectb=./projectb.pem . Perhatikan bahwa bahkan jika Anda menentukan kunci yang sebenarnya, hanya koneksi agen yang dikirim ke tautan, bukan konten sebenarnya dari kunci pribadi ini.
Dengan ini, peninjauan fitur baru rahasia pembuatan di Docker 18.09 selesai. Saya berharap bahwa fitur-fitur baru akan membantu untuk memanfaatkan lebih besar kemampuan Dockerfile dalam proyek-proyek dan memberikan tingkat keamanan yang lebih tinggi untuk jalur perakitan.