Apakah ciri keselamatan docker?

Ciri keselamatan Docker termasuk: 1. ID nod yang disulitkan; 2. Mekanisme pengesahan berasaskan TLS 3. Token akses keselamatan 4. Konfigurasi CA yang menyokong pembaharuan automatik sijil berkala; . Rangkaian yang disulitkan; 7. Pengimbasan keselamatan Docker;

Persekitaran pengendalian tutorial ini: sistem linux5.9.8, versi docker-1.13.1, komputer Dell G3.

Platform Docker juga memperkenalkan sejumlah besar teknologi keselamatannya sendiri. Mod Swarm dibina pada TLS dan sangat mudah dan fleksibel untuk dikonfigurasikan. Keselamatan mengimbas mengimbas imej pada tahap kod sumber binari dan menyediakan laporan terperinci tentang kelemahan yang diketahui.

Kepercayaan kandungan Docker membolehkan pengguna menandatangani dan memperakui kandungan, dan kunci kini menjadi warga kelas pertama di Docker. Docker menetapkan nilai lalai yang munasabah untuk teknologi keselamatan ini, tetapi pengguna juga boleh mengubah suai konfigurasi atau melumpuhkan teknologi keselamatan ini.

Mod Swarm

Mod Swarm ialah aliran masa hadapan Docker. Mod Swarm membolehkan pengguna mengurus berbilang hos Docker dalam kelompok dan menggunakan aplikasi secara deklaratif.

Setiap Swarm terdiri daripada nod pengurus dan pekerja, dan nod boleh Linux atau Windows. Nod pengurus membentuk lapisan kawalan dalam kelompok dan bertanggungjawab untuk konfigurasi kelompok dan pengagihan beban kerja. Nod pekerja ialah bekas yang menjalankan kod aplikasi.

Seperti yang dijangka, mod Swarm menyertakan banyak ciri keselamatan di luar kotak, sambil turut menetapkan lalai yang wajar. Ciri-ciri keselamatan ini termasuk yang berikut.

• ID nod yang disulitkan.

• Mekanisme pengesahan berasaskan TLS.

• Token akses selamat.

• Konfigurasi CA yang menyokong kemas kini automatik sijil berkala.

• Storan kelompok yang disulitkan (konfigurasi DB).

• Rangkaian disulitkan.

Imbasan Keselamatan Docker

Keupayaan untuk mencari kelemahan kod dengan cepat adalah kritikal. Pengimbasan Keselamatan Docker memudahkan untuk mengesan kelemahan yang diketahui dalam imej Docker.

Pengimbasan keselamatan Docker kini tersedia untuk imej repositori peribadi di Docker Hub. Pada masa yang sama, teknologi ini juga boleh digunakan sebagai sebahagian daripada penyelesaian penggunaan penyetempatan perkhidmatan yang dipercayai Docker. Akhirnya, semua imej Docker rasmi telah diimbas keselamatan, dan laporan imbasan tersedia dalam repositori mereka.

Pengimbasan Keselamatan Docker mengimbas imej Docker pada tahap kod binari dan menyemak perisian di dalamnya terhadap pangkalan data kelemahan yang diketahui (pangkalan data CVE). Selepas imbasan selesai, laporan terperinci dihasilkan.

Buka penyemak imbas untuk melawat Docker Hub dan cari repositori Alpine. Imej di bawah menunjukkan tab Tag bagi repositori Alpine rasmi.

Gudang Alpine ialah gudang rasmi, yang bermaksud gudang akan mengimbas dan menjana laporan yang sepadan secara automatik. Seperti yang anda lihat, imej dengan tag imej tepi, lewat dan 3.6 semuanya telah lulus pemeriksaan untuk kecacatan yang diketahui. Walau bagaimanapun, imej alpine:3.5 mempunyai kecacatan yang diketahui (ditandakan dengan warna merah).

Jika anda membuka imej alpine:3.5, anda boleh mendapatkan maklumat terperinci seperti yang ditunjukkan di bawah.

Ini ialah cara mudah untuk menemui butiran kecacatan yang diketahui dalam perisian anda sendiri.

Docker Trusted Registry (DTR) ialah sebahagian daripada perkhidmatan gudang imej setempat dalam Docker Enterprise Edition. Ia menyediakan keupayaan yang sama dan juga membolehkan pengguna mengawal masa pengimbasan imej dan kaedah pengimbasan mereka sendiri.

Sebagai contoh, DTR membenarkan pengguna memilih sama ada imej harus mencetuskan pengimbasan secara automatik apabila ditolak, atau hanya secara manual. Pada masa yang sama, DTR juga membenarkan pengguna mengemas kini pangkalan data CVE secara manual, yang merupakan penyelesaian ideal untuk senario di mana DTL tidak dapat menyambung ke Internet untuk mengemas kini data CVE secara automatik.

Ini ialah Pengimbasan Keselamatan Docker, cara terbaik untuk memeriksa imej Docker secara mendalam untuk mengesan kelemahan keselamatan yang diketahui. Sudah tentu, dengan keupayaan yang lebih besar datang tanggungjawab yang lebih besar Apabila pengguna menemui kecacatan, mereka perlu bertanggungjawab untuk menyelesaikan kecacatan yang sepadan.

Docker Content Trust

Dockr Content Trust (DCT) memudahkan pengguna mengesahkan integriti imej yang dimuat turun dan penerbitnya. Ini penting apabila memuat turun imej dalam persekitaran rangkaian yang tidak dipercayai.

Pada tahap yang tinggi, DCT membenarkan pembangun menandatangani imej yang diterbitkan ke Docker Hub atau Docker Trusted Services. Apabila imej ini ditarik, status tandatangan akan disahkan secara automatik. Imej di bawah menggambarkan proses ini.

DCT juga boleh menyediakan konteks utama, seperti sama ada imej telah ditandatangani dan boleh digunakan dalam persekitaran pengeluaran, sama ada imej telah digantikan dengan versi baharu dan menjadi usang, dsb.

Konteks yang disediakan oleh DTC masih di peringkat awal dan agak rumit untuk dikonfigurasikan. Untuk mendayakan fungsi DCT pada hos Docker, anda hanya perlu menetapkan pembolehubah DOCKER_CONTENT_TRUST kepada 1 dalam persekitaran anda.

$ export DOCKER_CONTENT_TRUST=1

Dalam persekitaran sebenar, pengguna mungkin mahu mendayakan ciri ini secara lalai dalam sistem.

Jika anda menggunakan lapisan konfigurasi bersatu Docker (sebahagian daripada Docker Enterprise Edition), anda perlu menyemak kotak semak Run Only Signed Images seperti yang ditunjukkan dalam rajah di bawah. Ini akan memaksa semua nod dalam kluster UCP untuk menjalankan hanya imej yang ditandatangani.

Seperti yang dapat dilihat daripada rajah di atas, UCP dirangkumkan lagi berdasarkan DCT untuk menyediakan maklumat keutamaan keselamatan untuk imej yang ditandatangani. Sebagai contoh, pengguna mungkin mempunyai keperluan sedemikian: hanya imej yang ditandatangani oleh secops boleh digunakan dalam persekitaran pengeluaran.

Setelah fungsi DCT didayakan, imej yang tidak ditandatangani tidak boleh diperoleh dan digunakan. Angka berikut menunjukkan ralat yang dilaporkan apabila cuba menarik imej yang tidak ditandatangani melalui antara muka Docker CLI atau UCP Web UI sekali lagi selepas menghidupkan DCT (kedua-dua contoh cuba menarik imej yang berlabel "tidak ditandatangani").

Rajah berikut menunjukkan cara DCT menghalang klien Docker daripada menarik imej yang diusik.

Imej di bawah menunjukkan cara DCT menghalang pelanggan daripada menarik imej lama.

Kepercayaan kandungan Docker ialah teknologi penting yang membantu pengguna menyemak imej yang diambil daripada perkhidmatan Docker. Mod asas teknologi ini sangat mudah untuk dikonfigurasi, tetapi beberapa ciri lanjutan seperti konteks masih sangat rumit untuk dikonfigurasikan pada peringkat ini.

Docker Key

Banyak aplikasi memerlukan kunci. Seperti kata laluan, sijil TLS, kunci SSH, dsb.

Sebelum Docker versi 1.13, tiada cara standard dan selamat untuk berkongsi kunci antara aplikasi. Cara biasa adalah untuk pembangun menulis kunci sebagai teks ke dalam pembolehubah persekitaran. Ini jauh dari ideal.

Docker1.13 memperkenalkan kunci Docker, mengubah kunci menjadi warga kelas pertama dalam ekosistem Docker. Sebagai contoh, rahsia docker subperintah baharu telah ditambahkan untuk mengurus kunci. Terdapat juga tempat khusus untuk mencipta dan mengurus kunci dalam antara muka UCP Docker.

Di latar belakang, kunci disulitkan selepas penciptaan dan semasa penghantaran, dipasang pada sistem fail memori apabila digunakan dan hanya boleh diakses oleh perkhidmatan yang dibenarkan. Ini benar-benar penyelesaian menyeluruh dari hujung ke hujung.

Rajah di bawah menunjukkan keseluruhan proses.

Setiap langkah aliran kerja yang ditunjukkan dalam gambar di atas diperkenalkan di bawah.

1) Kunci dicipta dan dihantar ke Swarm.

2) Kunci disimpan dalam storan kluster dan disulitkan (setiap nod pengurus boleh mengakses storan kluster).

3) Perkhidmatan B dibuat dan kunci digunakan.

4) Proses penghantaran kunci ke nod tugas (bekas) perkhidmatan B disulitkan.

5) Bekas perkhidmatan B menyahsulit kunci dan melekapkannya ke laluan /run/secrets. Ini ialah sistem fail dalam memori sementara (langkah ini berbeza dalam Windows Docker kerana tiada konsep sistem fail dalam memori dalam Windows).

6) Setelah bekas (tugas perkhidmatan) selesai, sistem fail memori ditutup dan kunci dipadamkan.

7) Bekas dalam perkhidmatan A tidak boleh mengakses kunci.

Pengguna boleh mengurus kunci melalui subperintah rahsia docker, dan boleh menentukan kunci untuk perkhidmatan dengan menambahkan --secret apabila menjalankan arahan cipta perkhidmatan docker.

Pembelajaran yang disyorkan: "tutorial video buruh pelabuhan"

Atas ialah kandungan terperinci Apakah ciri keselamatan docker?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!