Runtime kontainer sandbox menjalankan aplikasi dan dependensinya dalam mesin virtual ringan. Runtime ini menyediakan kernel independen atau lapisan isolasi terperinci untuk pod aplikasi, sehingga membantu mencegah serangan berbahaya atau kerentanan keamanan di dalam kontainer agar tidak memengaruhi host atau kontainer lainnya. Topik ini menjelaskan arsitektur, manfaat utama, serta skenario penggunaan umum kontainer sandbox.
Informasi latar belakang
Kontainer sandbox sangat ideal untuk skenario seperti mengisolasi aplikasi yang tidak tepercaya, isolasi kesalahan, isolasi kinerja, dan mengisolasi beban kerja antar beberapa pengguna. Kontainer ini meningkatkan keamanan dengan dampak minimal terhadap kinerja serta memberikan pengalaman pengguna yang sama seperti kontainer Docker untuk fitur-fitur seperti logging, pemantauan, dan skalabilitas elastis.
Dibandingkan dengan solusi komunitas (Kata Containers), kontainer sandbox menawarkan optimasi dan peningkatan dalam penyimpanan, jaringan, serta stabilitas.
Arsitektur
Manfaat utama
Sandboxed Container V2 adalah runtime kontainer aman generasi berikutnya dari Alibaba Cloud yang didasarkan pada teknologi mesin virtual ringan. Dibandingkan dengan V1, runtime ini mempertahankan isolasi kuat sekaligus mengurangi overhead hingga 90%, meningkatkan kecepatan startup hingga tiga kali lipat, dan meningkatkan kerapatan per mesin hingga sepuluh kali lipat. Manfaat utamanya adalah sebagai berikut:
Menyediakan isolasi kuat antar sandbox berdasarkan mesin virtual ringan.
Menawarkan kompatibilitas aplikasi dengan kontainer runC tradisional.
Memberikan kinerja aplikasi secara keseluruhan yang tinggi, mencapai hingga 90% dari kinerja aplikasi kontainer runC.
Mendukung pemasangan dan berbagi NAS, cloud disk, dan Volume OSS dalam mode sandbox menggunakan virtiofs. NAS juga mendukung penyambungan langsung dalam mode sandbox.
Memberikan pengalaman pengguna yang konsisten dengan runC untuk pemantauan, logging, dan penyimpanan.
Mendukung RuntimeClass (runC dan runV). Untuk informasi selengkapnya, lihat RuntimeClass.
Mudah digunakan dan tidak memerlukan keahlian teknis yang mendalam.
Menawarkan stabilitas lebih tinggi dibandingkan Kata Containers dari komunitas. Untuk informasi selengkapnya tentang Kata Containers, lihat Kata Containers.
Perbandingan antara kontainer sandbox ACK dan Kata Containers komunitas
Kinerja | Kategori kinerja | ACK Sandboxed Container V2 | Community Kata Containers |
Kecepatan startup sandbox | Sekitar 150 ms | Sekitar 500 ms | |
Overhead tambahan sandbox | Rendah | Tinggi | |
Container RootFS | virtio-fs, Kinerja: ☆☆☆☆ |
| |
Container Persistent Volume | HostPath/EmptyDir | virtio-fs, Kinerja: ☆☆☆☆ | |
Penyimpanan blok cloud disk | virtio-fs, Kinerja: ☆☆☆☆ Tidak mendukung fitur seperti penskalaan online (Resize), pemantauan I/O kontainer, perangkat blok/raw, atau pengaturan antrian cloud disk. | ||
Penyimpanan file NAS |
Tidak mendukung fitur seperti pemasangan dan pencopotan Samba, Keranjang daur ulang, kontrol kapasitas Quota, pemantauan kapasitas/I/O, atau penskalaan online. | ||
Penyimpanan Objek OSS | virtio-fs, Kinerja: ☆☆☆☆ | ||
Plugin jaringan |
| Flannel | |
Pemantauan dan Peringatan |
| Tidak memiliki metrik pemantauan disk dan jaringan untuk pod kontainer sandbox. | |
Stabilitas | ☆☆☆☆☆ | ☆☆ | |
Skenario penggunaan kontainer sandbox ACK
Skenario 1: Isolasi aplikasi yang tidak tepercaya dengan pemisahan kuat menggunakan kontainer sandbox (runV)
Risiko keamanan kontainer runC
Kontainer yang menggunakan teknologi namespace dan cgroup untuk isolasi memiliki permukaan serangan yang luas.
Semua kontainer pada satu node berbagi kernel host. Jika kerentanan kernel dieksploitasi, kode berbahaya dapat keluar dari kontainer menuju host. Hal ini memungkinkan kode tersebut menembus jaringan pribadi backend, menjalankan kode dengan hak istimewa, mengganggu layanan sistem dan aplikasi lain, serta mencuri data penting.
Kerentanan pada aplikasi itu sendiri juga dapat memungkinkan penyerang menembus jaringan pribadi.
Anda dapat mengurangi risiko keamanan kontainer runC dengan langkah-langkah berikut:
Seccomp: Menyaring panggilan sistem.
SELinux: Membatasi izin proses, file, dan pengguna kontainer.
Capability: Membatasi kemampuan proses kontainer.
Mode rootless: Mencegah pengguna menjalankan runtime kontainer dan kontainer sebagai pengguna root.
Meskipun langkah-langkah ini dapat meningkatkan keamanan kontainer runC, langkah tersebut tidak dapat mencegah pelarian kontainer yang mengeksploitasi kerentanan kernel host.
Isolasi potensi risiko keamanan dengan kontainer sandbox (runV)
Saat Anda menempatkan aplikasi yang berpotensi berisiko ke dalam sandbox mesin virtual ringan, aplikasi tersebut berjalan pada kernel OS tamu yang independen. Bahkan jika terjadi kerentanan keamanan pada kernel OS tamu, dampaknya terbatas hanya pada satu sandbox dan tidak memengaruhi kernel host atau kontainer lainnya. Anda dapat menggabungkan kontainer sandbox (runV) dengan fitur Terway NetworkPolicy untuk mengonfigurasi kebijakan akses jaringan pod secara fleksibel. Kombinasi ini mencapai isolasi sistem, data, dan jaringan yang sesungguhnya.
Skenario 2: Mengatasi masalah pada kontainer runC, seperti amplifikasi kesalahan, konflik sumber daya, dan gangguan kinerja
Kubernetes memudahkan penyebaran berbagai kontainer aplikasi pada satu node yang sama. Namun, karena cgroups tidak secara efektif menyelesaikan konflik sumber daya, aplikasi yang intensif sumber daya—seperti aplikasi intensif CPU atau I/O—pada satu node saling bersaing untuk sumber daya. Persaingan ini menyebabkan fluktuasi signifikan pada waktu respons aplikasi dan meningkatkan waktu respons secara keseluruhan. Saat sebuah aplikasi pada node mengalami masalah, seperti memory leak atau core dump yang sering terjadi, beban node secara keseluruhan meningkat. Satu kontainer yang memicu bug kernel host dapat menyebabkan sistem mati. Kesalahan pada satu aplikasi dapat menyebar ke seluruh node dan bahkan menyebabkan seluruh kluster menjadi tidak responsif. Kontainer sandbox (runV) menggunakan kernel OS tamu yang independen dan hypervisor untuk secara efektif mengatasi masalah amplifikasi kesalahan, konflik sumber daya, dan gangguan kinerja yang terdapat pada kontainer runC.
Skenario 3: Layanan multi-penyewa
Umumnya, suatu perusahaan memiliki beberapa lini bisnis (LOB) atau departemen yang men-deploy aplikasi mereka sendiri. LOB atau departemen yang berbeda ini (multi-penyewa) memiliki persyaratan isolasi yang kuat. Misalnya, bisnis yang berkaitan dengan keuangan mungkin tidak ingin lingkungan fisik mereka menjalankan aplikasi lain yang tidak sensitif terhadap keamanan. Kontainer runC tradisional tidak dapat secara efektif mencegah risiko keamanan potensial yang ditimbulkan oleh aplikasi yang tidak tepercaya. Dalam kasus ini, Anda biasanya akan memilih salah satu opsi berikut:
Kluster single-tenant ganda: Misalnya, Anda dapat memisahkan kluster bisnis keuangan dari kluster bisnis non-sensitif keamanan lainnya.
Satu kluster multi-penyewa: Anda dapat memisahkan aplikasi dari LOB yang berbeda ke dalam namespace yang berbeda. Setiap node dapat digunakan secara eksklusif oleh LOB tertentu. Isolasi multi-penyewa dicapai menggunakan kuota sumber daya, kebijakan jaringan, dan fitur lainnya. Dibandingkan dengan penggunaan beberapa kluster single-tenant, pendekatan ini menggunakan lebih sedikit lapisan kontrol dan memiliki biaya manajemen yang lebih rendah. Namun, pendekatan ini tidak menyelesaikan masalah pemborosan sumber daya node akibat pemanfaatan sumber daya yang rendah oleh beberapa penyewa.
Dengan kontainer sandbox (runV), Anda dapat mengisolasi aplikasi yang tidak tepercaya di dalam kluster menggunakan sandbox mesin virtual tanpa khawatir terhadap risiko keamanan akibat pelarian kontainer. Hal ini memungkinkan Anda menjalankan campuran berbagai kontainer aplikasi pada semua node. Manfaatnya adalah sebagai berikut:
Mengurangi kompleksitas penjadwalan sumber daya.
Node tidak lagi digunakan secara eksklusif oleh satu bisnis. Hal ini mengurangi fragmentasi sumber daya, meningkatkan pemanfaatan sumber daya node, dan menghemat biaya sumber daya kluster secara keseluruhan.
Kontainer sandbox (runV) menggunakan mesin virtual ringan dan memberikan kinerja yang sebanding dengan kontainer runC.
Batasan
Versi kluster: Hanya Kluster ACK yang dikelola dan Cluster khusus ACK versi 1.16 hingga 1.34 yang didukung. Untuk melakukan upgrade kluster, lihat Upgrade kluster secara manual.
Sistem operasi: Kelompok node kontainer sandbox tidak mendukung gambar kustom.
Untuk kluster yang menjalankan versi sebelum 1.30, hanya Alibaba Cloud Linux 3 dan Alibaba Cloud Linux 2 (maintenance telah dihentikan) yang didukung.
Untuk kluster yang menjalankan versi 1.30 atau lebih baru, hanya Alibaba Cloud Linux 3 yang didukung.
Tipe instance: Hanya tipe Instance ECS Bare Metal yang didukung.
Plugin jaringan: Kelompok node kontainer sandbox hanya mendukung plugin jaringan Flannel dan plugin jaringan Terway dalam beberapa mode tertentu. Saat Anda menggunakan plugin jaringan Terway, mode ENI khusus tidak didukung dan fitur DataPath v2 tidak dapat diaktifkan.