Runtime Kontainer-Sandbox menjalankan aplikasi dalam VM ringan yang terisolasi dari sistem lainnya. Arsitektur ini menetapkan isolasi tingkat kernel untuk pod aplikasi sambil mempertahankan pemisahan lingkungan yang ketat dari infrastruktur host. Mekanisme ini secara efektif melindungi host atau kontainer lain terhadap serangan atau kerentanan di dalam kontainer sandbox. Topik ini menjelaskan arsitektur, manfaat, dan skenario penggunaan Kontainer-Sandbox.
Informasi Latar Belakang
Kontainer-Sandbox cocok digunakan dalam skenario seperti isolasi aplikasi tidak tepercaya, isolasi kesalahan, isolasi kinerja, dan isolasi beban di antara beberapa pengguna. Kontainer-Sandbox menyediakan keamanan yang ditingkatkan, memiliki dampak kecil pada kinerja aplikasi, dan menawarkan pengalaman pengguna yang sama dengan Docker dalam hal pencatatan, pemantauan, dan skalabilitas elastis.
Dibandingkan dengan Kata Containers open-source, Kontainer-Sandbox dioptimalkan dalam hal penyimpanan, jaringan, dan stabilitas.
Arstitektur
Fitur Utama
Kontainer-Sandbox adalah runtime pengamanan kontainer yang dikembangkan oleh Alibaba Cloud. Dibandingkan dengan Kontainer-Sandbox V1, Kontainer-Sandbox V2 mempertahankan performa isolasi yang sama dan mengurangi overhead pod sebesar 90%. Ini juga memungkinkan Anda memulai kontainer sandbox 3 kali lebih cepat dan meningkatkan jumlah maksimum pod yang dapat diterapkan pada host sebanyak 10 kali. Kontainer-Sandbox V2 menyediakan fitur utama berikut:
Isolasi kuat berdasarkan sandbox dan VM ringan.
Kompatibilitas dengan runC dalam hal manajemen aplikasi.
Kinerja tinggi yang setara dengan 90% performa aplikasi berbasis runC.
File Storage NAS (NAS) file system, disk Alibaba Cloud, dan Bucket OSS dapat dipasang ke kontainer sandbox melalui virtio-fs. Sistem file NAS juga dapat langsung dipasang ke kontainer sandbox.
Pengalaman pengguna yang sama dengan runC dalam hal pencatatan, pemantauan, dan penyimpanan.
Dukungan untuk RuntimeClass (runC dan runV). Untuk informasi lebih lanjut, lihat RuntimeClass.
Kemudahan penggunaan dengan persyaratan keterampilan teknis minimal.
Stabilitas lebih tinggi dibandingkan runtime Kata Containers open source. Untuk informasi lebih lanjut tentang Kata Containers, lihat Kata Containers.
Perbandingan antara Kontainer-Sandbox dan Kata Containers
Item | Kategori | Kontainer-Sandbox V2 | Kata Containers |
Jumlah waktu yang dibutuhkan untuk memulai sandbox | Sekitar 150 ms | Sekitar 500 ms | |
Overhead tambahan sandbox | Rendah | Tinggi | |
Root file system | virtio-fs. Performa: ☆☆☆☆ |
| |
Volume | HostPath/EmptyDir | virtio-fs. Performa: ☆☆☆☆ | |
Disk dengan penyimpanan blok | virtio-fs. Performa: ☆☆☆☆ | ||
NAS |
| ||
Object Storage Service (OSS) | virtio-fs. Performa: ☆☆☆☆ | ||
Plugin jaringan |
| Flannel | |
Pemantauan dan peringatan |
| Pemantauan disk dan kondisi jaringan tidak tersedia untuk pod yang menggunakan Kontainer-Sandbox. | |
Stabilitas | ☆☆☆☆☆ | ☆☆ | |
Skenario Penggunaan Kontainer-Sandbox
Skenario 1: Dibandingkan dengan runC, Kontainer-Sandbox (runV) menyediakan isolasi tingkat kernel untuk aplikasi tidak tepercaya
Risiko keamanan runC
runC mengisolasi kontainer dengan menggunakan namespace dan grup kontrol (cgroups). Hal ini membuat kontainer rentan terhadap risiko keamanan.
Semua kontainer pada node berbagi kernel host. Jika kernel memiliki kerentanan, kode jahat dapat melarikan diri ke host dan kemudian menyusup ke jaringan backend. Eksekusi kode jahat dapat menyebabkan peningkatan hak istimewa, membahayakan data sensitif, dan merusak layanan sistem serta aplikasi lainnya.
Penyerang juga dapat mengeksploitasi kerentanan aplikasi untuk menyusup ke jaringan internal.
Anda dapat menerapkan langkah-langkah berikut untuk mengurangi risiko keamanan kontainer dalam runC.
Seccomp: menyaring panggilan sistem.
SElinux: membatasi izin proses kontainer, file, dan pengguna.
Capability: membatasi kemampuan proses kontainer.
Mode tanpa root: melarang pengguna menjalankan runtime kontainer dan kontainer sebagai peran root.
Langkah-langkah di atas dapat meningkatkan keamanan kontainer dalam runC dan mengurangi serangan terhadap kernel host dengan menggunakan kontainer jahat. Namun, masalah pelarian kontainer dan kerentanan kernel host tetap belum terselesaikan.
Risiko keamanan runV
runV mengimplementasikan isolasi tingkat kernel melalui sandbox VM ringan yang divalidasi, di mana beban kerja tidak tepercaya beroperasi pada kernel OS tamu khusus. Dalam hal kompromi kernel tamu, permukaan serangan secara ketat terbatas dalam sandbox yang terpengaruh, sehingga memastikan perlindungan penuh terhadap kernel host dan lingkungan kontainer yang berdekatan.
Saat diintegrasikan dengan kemampuan NetworkPolicy yang ditingkatkan dari Terway, arsitektur ini memungkinkan konfigurasi granular kontrol akses jaringan pod, memberikan isolasi multi-dimensi termasuk batas sistem, bidang data, dan segmen jaringan.
Skenario 2: Mitigasi amplifikasi kegagalan, perebutan sumber daya, dan gangguan kinerja dalam lingkungan kontainer runC
Kubernetes memungkinkan Anda menerapkan kontainer berbeda pada satu node dengan mudah. Namun, cgroups tidak dioptimalkan untuk mengatasi perebutan sumber daya. Aplikasi intensif sumber daya seperti aplikasi intensif CPU dan I/O mungkin bersaing untuk sumber daya yang sama. Hal ini menyebabkan fluktuasi signifikan dalam waktu respons dan meningkatkan waktu respons keseluruhan. Pengecualian atau kesalahan pada aplikasi dapat menyebar ke node hosting dan mengganggu operasi klaster. Misalnya, kebocoran memori dan core dump yang sering dari aplikasi dapat membebani node, dan pengecualian pada kontainer dapat memicu bug kernel host yang mengakibatkan kegagalan sistem total. Melalui kernel OS tamu khusus dan hypervisor, Kontainer-Sandbox menyelesaikan masalah umum dengan kontainer runC. Masalah tersebut mencakup penyebaran kegagalan, perebutan sumber daya, dan gangguan kinerja.
Skenario 3: Layanan multi-penyewa
Anda mungkin perlu mengisolasi aplikasi perusahaan yang terdiri dari beberapa lini bisnis atau departemen. Misalnya, departemen keuangan memerlukan aplikasi dengan keamanan tinggi. Namun, aplikasi lain yang tidak sensitif terhadap keamanan tidak memiliki persyaratan keamanan tinggi. Kontainer dalam runC gagal menghilangkan risiko potensial yang terjadi pada aplikasi tidak tepercaya. Dalam skenario ini, Anda dapat menerapkan tindakan berikut:
Menyebarkan beberapa klaster single-tenant independen. Misalnya, menyebarkan bisnis keuangan dan bisnis lain yang tidak sensitif terhadap keamanan di klaster berbeda.
Menyebarkan klaster multi-penyewa dan memisahkan aplikasi dari lini bisnis berbeda dengan menggunakan namespace. Sumber daya node menjadi eksklusif untuk satu lini bisnis. Solusi ini menyediakan isolasi data untuk koordinasi dengan kuota sumber daya dan kebijakan jaringan untuk mengimplementasikan isolasi multi-penyewa. Dibandingkan dengan beberapa klaster single-tenant, solusi ini fokus pada lebih sedikit bidang manajemen dan dengan demikian mengurangi biaya manajemen. Namun, solusi ini tidak dapat mencegah pemborosan sumber daya pada node yang disebabkan oleh rendahnya pemanfaatan sumber daya beberapa penyewa.
Kontainer-Sandbox memungkinkan Anda mengisolasi aplikasi tidak tepercaya dengan menggunakan mesin virtual sandbox. Ini mencegah risiko pelarian kontainer. Ini juga memungkinkan Anda menerapkan aplikasi kontainer berbeda pada setiap node, yang membawa manfaat berikut:
Penjadwalan sumber daya disederhanakan.
Node tidak lagi eksklusif untuk satu layanan. Ini meningkatkan penggunaan sumber daya node dan mengurangi fragmen sumber daya serta biaya sumber daya klaster.
Kontainer sandbox menggunakan mesin virtual ringan untuk memberikan performa hampir sama dengan kontainer dalam runC.
Catatan Penggunaan
Versi klaster: Didukung hanya untuk klaster ACK managed cluster dan ACK dedicated cluster yang menjalankan Kubernetes 1.16 atau lebih baru. Untuk meningkatkan klaster, lihat Tingkatkan Klaster ACK Secara Manual.
Sistem operasi: Gambar kustom tidak didukung oleh pool node yang berjalan dalam kontainer sandbox.
Klaster di bawah v1.30: Hanya Alibaba Cloud Linux 3 dan Alibaba Cloud Linux 2 (EOL).
Klaster v1.30+: Hanya Alibaba Cloud Linux 3.
Spesifikasi instance: Hanya keluarga instance ECS Bare Metal Instance.
Plugin jaringan:
Flannel (didukung sepenuhnya)
Terway (dengan batasan): Mode ENI eksklusif dan mode DataPath V2 tidak didukung.