Konteks dan cakupan
Anda mengoperasikan kluster Kubernetes multi-tenant pada node Linux yang menjalankan SELinux dalam mode enforcing. Platform ini menggunakan volume CSI, dan beberapa beban kerja berbagi volume. Tim berencana untuk melakukan upgrade ke v1.36. Rancang pemeriksaan kompatibilitas, rollout canary, observabilitas, dan rollback tanpa berasumsi bahwa setiap node mengaktifkan SELinux.
Hal yang diuji oleh pewawancara
Pewawancara ingin Anda memisahkan node SELinux dari node biasa, menjelaskan perbedaan antara konteks mount dan pelabelan ulang rekursif, serta mengidentifikasi risiko ketika Pod privileged dan unprivileged berbagi volume. Jawaban yang kuat juga mencakup driver CSI, securityContext Pod, latensi startup, akses data, batasan admisi, dan rollback versi.
Pertanyaan klarifikasi di awal
- Node mana yang berstatus enforcing, serta driver CSI dan sistem berkas apa saja yang berada dalam cakupan yang didukung?
- Apakah penyimpanan bersama merupakan batasan bisnis yang mutlak, atau apakah volume dapat dipecah atau data dapat dipertukarkan secara eksplisit?
- Apakah migrasi ini mengoptimalkan latensi startup, isolasi tenant, kontinuitas beban kerja, atau trade-off yang eksplisit?
- Apakah versi yang di-deploy mengizinkan kebijakan pelabelan eksplisit, dan apa persyaratan jendela rollback serta retensi bukti?
Jawaban 30 detik
“Saya akan menginventarisasi mode SELinux node, driver CSI, jenis volume, dan hubungan pembagian terlebih dahulu. Peningkatan di v1.36 menggunakan konteks mount untuk volume yang didukung, mengurangi biaya pelabelan ulang rekursif tetapi berpotensi mengubah hasil akses untuk volume bersama. Saya akan menjalankan beban kerja yang setara dalam kumpulan node (node pool) yang terisolasi, memeriksa mount, label, operasi baca dan tulis, latensi startup, serta log penolakan sebelum memperluasnya. Jika batas pengaman (guardrail) gagal, saya akan menghentikan beban kerja baru, mempertahankan Pod yang sedang berjalan beserta buktinya, dan melakukan rollback menggunakan kebijakan yang didukung oleh versi yang di-deploy.”
Solusi langkah demi langkah
1. Buat inventaris dampak
Catat kernel dan status SELinux setiap node, mode enforcing atau permissive, versi Kubernetes, versi driver CSI, dan jenis volume. Ekspor seLinuxOptions, identitas, tingkat hak istimewa, jalur mount, dan hubungan pembagian dari setiap Pod. Node tanpa SELinux tidak boleh dimasukkan ke dalam kesimpulan perilaku yang sama.
2. Jelaskan perubahan perilaku
Perubahan Kubernetes membuat peningkatan pelabelan volume SELinux menjadi stabil di v1.36. Untuk volume yang didukung, sistem dapat menggunakan konteks mount alih-alih melabeli ulang setiap berkas secara rekursif. Hal ini biasanya mengurangi pekerjaan startup untuk volume besar, tetapi asumsi bahwa volume bersama dilabeli ulang sebelum digunakan dapat gagal ketika domain keamanan yang berbeda mengaksesnya. Mount yang berhasil tidak membuktikan bahwa aplikasi dapat membaca dan menulis.
3. Periksa batas driver dan kebijakan
Untuk setiap driver CSI, verifikasi dukungan untuk konteks mount, perilaku sistem berkas, dan pembatasan opsi mount. Periksa dokumentasi versi yang di-deploy untuk seLinuxChangePolicy, feature gate terkait, dan nilai default; jangan menyalin kolom atau beralih dari rilis lama tanpa verifikasi. Kebijakan admisi harus membatasi hak istimewa yang tidak perlu, menentukan domain keamanan volume bersama, dan mengaudit perubahan.
4. Jalankan perbandingan yang dapat direproduksi
Siapkan Pod uji dengan image, UID/GID, securityContext, dan data volume yang sama. Cakup Pod tunggal, pembagian domain yang sama, pembagian privileged dan unprivileged, volume kosong, serta volume yang berisi banyak berkas. Verifikasi konteks mount, label berkas, baca dan tulis, pemulihan restart, ekspansi, dan penyambungan ulang CSI. Ukur setiap interval dari pembuatan Pod hingga Ready.
5. Tambahkan guardrail canary
Buat node pool khusus dan sejumlah kecil StorageClass CSI, lalu mulai dengan job yang dapat dicoba ulang (retryable). Jangan memberikan kombinasi domain keamanan yang belum diverifikasi ke volume bersama yang sama selama canary. Tetapkan ambang batas untuk log penolakan, kegagalan mount, kesalahan izin aplikasi, latensi startup, dan keberhasilan restart. Hentikan ekspansi ketika guardrail terpicu; jangan menyembunyikan masalah dengan memperluas SELinux atau hak istimewa.
6. Tangani risiko volume bersama
Ketika sebuah volume digunakan bersama oleh Pod privileged dan unprivileged, pisahkan volume terlebih dahulu atau satukan domain keamanan sebelum melanjutkan. Untuk pembagian yang tidak dapat dihindari, tentukan siapa pemilik pelabelan, kapan volume di-mount, dan bagaimana volume direklamasi, kemudian validasi matriks akses yang sebenarnya. Hapus volume lama hanya setelah pemulihan aplikasi terbukti, sehingga masalah pelabelan tidak disalahartikan sebagai kehilangan data.
7. Pertahankan bukti rollback
Rollback dimulai dengan menghentikan Pod baru agar tidak masuk ke pool canary sambil mempertahankan job dan event yang sedang berjalan. Kemudian pilih kebijakan rekursif yang didukung secara eksplisit atau node pool yang lebih lama untuk versi yang di-deploy. Simpan pengaturan feature-gate, label node, konfigurasi CSI, manifes Pod, dan log penolakan AVC SELinux. Jalankan kembali perbandingan yang sama setelah rollback; perintah deployment yang berhasil saja bukanlah bukti pemulihan.
Contoh jawaban
Saya akan menyusun migrasi ini menjadi inventaris, perbandingan, canary, dan rollback. Hanya node Linux dengan SELinux yang tersedia dalam mode enforcing yang masuk dalam cakupan, dan dukungan driver CSI harus diperiksa terhadap versi Kubernetes yang di-deploy. v1.36 menggunakan konteks mount untuk volume yang didukung, mengurangi pelabelan ulang rekursif tetapi memerlukan pengujian terfokus untuk volume bersama dan domain keamanan yang berbeda. Pengujian mencakup volume kosong dan besar, satu Pod, pembagian domain yang sama, dan pembagian privileged/unprivileged; membandingkan label, akses, log penolakan, latensi startup, dan pemulihan restart. Pool canary hanya menerima pekerjaan yang dapat dicoba ulang. Ambang batas yang gagal akan menghentikan ekspansi, mempertahankan bukti, dan mengembalikan pekerjaan baru ke jalur terdokumentasi yang didukung.
Kesalahan umum
- Memperlakukan setiap node sebagai node SELinux → cakupan dampak menjadi salah → partisi berdasarkan mode node dan status enforcing.
- Hanya menguji keberhasilan mount → akses runtime masih ditolak → uji identitas asli, label, baca, tulis, dan restart.
- Langsung memperluas hak istimewa → batas keamanan melebar → perbaiki domain keamanan, hubungan pembagian, atau konfigurasi driver.
- Mengabaikan perbedaan CSI → satu kelas volume gagal dalam canary → buat matriks untuk driver, sistem berkas, dan jenis volume.
- Menghapus setiap Pod selama rollback → bukti hilang dan job berhenti → bekukan lalu lintas baru serta pertahankan state dan log.
Pertanyaan lanjutan dan tanggapan
Apakah mode permisif memerlukan migrasi yang sama?
Mode tersebut tetap perlu diinventarisasi dan diuji karena mode permissive mencatat penolakan tanpa benar-benar menerapkannya secara normal. Ini tidak merepresentasikan perilaku enforcing, sehingga release gate harus direproduksi pada node yang enforcing.
Bagaimana cara membedakan masalah pelabelan dari masalah CSI?
Pertahankan node, image, dan konteks keamanan secara konstan sambil mengganti jenis volume atau driver. Bandingkan event mount, penolakan kernel, label berkas, dan log CSI. Atribusikan masalah ke jalur konteks keamanan hanya jika masalah tersebut tereproduksi di berbagai driver.
Apakah startup yang lebih cepat cukup untuk membuktikan keberhasilan?
Tidak. Performa hanyalah salah satu sinyal. Matriks akses untuk domain yang berbeda, pemulihan restart, ekspansi, perilaku penyambungan ulang, dan bukti audit juga harus memenuhi release gate.
Bagaimana jika volume bersama tidak dapat menggunakan satu domain keamanan?
Lebih baik membagi volume atau menggunakan jalur pertukaran data yang eksplisit. Jika pembagian tidak dapat dihindari, platform harus memiliki wewenang atas domain keamanan dan keputusan siklus hidup, serta kombinasi Pod yang diizinkan harus ditegakkan dan diuji regresinya.