Gesaan dan skop
Anda mengendalikan kluster Kubernetes berbilang penyewa (multi-tenant) pada nod Linux yang menjalankan SELinux dalam mod enforcing. Platform ini menggunakan volum CSI, dan sesetengah beban kerja berkongsi volum. Pasukan merancang untuk menaik taraf kepada v1.36. Reka bentuk semakan keserasian, pelancaran canary, kebolehcerapan dan rollback tanpa menganggap bahawa setiap nod telah mendayakan SELinux.
Perkara yang diuji oleh penemu duga
Penemu duga mahu anda mengasingkan nod SELinux daripada nod biasa, menerangkan perbezaan antara konteks lekapan (mount context) dan pelabelan semula secara rekursif, serta mengenal pasti risiko apabila Pod berkeistimewaan (privileged) dan tanpa keistimewaan (unprivileged) berkongsi volum. Jawapan yang mantap juga merangkumi pemacu CSI, securityContext Pod, kependaman permulaan (startup latency), capaian data, sempadan kemasukan (admission boundaries) dan rollback berversi.
Soalan untuk dijelaskan terlebih dahulu
- Nod manakah yang berada dalam mod enforcing, dan pemacu CSI serta sistem fail manakah yang berada dalam skop sokongan?
- Adakah storan kongsi merupakan kekangan perniagaan yang mutlak, atau bolehkah volum dipecahkan atau data ditukar secara eksplisit?
- Adakah migrasi ini mengoptimumkan kependaman permulaan, pengasingan penyewa, kesinambungan beban kerja, atau pertukaran (trade-off) yang eksplisit?
- Adakah versi yang digunakan membenarkan dasar pelabelan eksplisit, dan apakah tetingkap rollback serta keperluan pengekalan bukti?
Jawapan 30 saat
“Saya akan menginventori mod SELinux nod, pemacu CSI, jenis volum dan hubungan perkongsian terlebih dahulu. Peningkatan v1.36 menggunakan konteks lekapan untuk volum yang disokong, mengurangkan kos pelabelan semula rekursif tetapi berpotensi mengubah hasil capaian untuk volum kongsi. Saya akan menjalankan beban kerja yang setara dalam kumpulan nod terasing, menyemak lekapan, label, baca dan tulis, kependaman permulaan dan log penafian sebelum mengembangkannya. Jika batas perlindungan (guardrail) gagal, saya akan menghentikan beban kerja baharu, mengekalkan Pod yang sedang berjalan dan bukti, serta melakukan rollback menggunakan dasar yang disokong oleh versi yang digunakan.”
Penyelesaian langkah demi langkah
1. Bina inventori impak
Catatkan kernel dan keadaan SELinux setiap nod, mod enforcing atau permissive, versi Kubernetes, versi pemacu CSI dan jenis volum. Eksport seLinuxOptions setiap Pod, identiti, tahap keistimewaan, laluan lekapan dan hubungan perkongsian. Nod tanpa SELinux tidak boleh dimasukkan ke dalam kesimpulan tingkah laku yang sama.
2. Terangkan perubahan tingkah laku
Perubahan Kubernetes menjadikan peningkatan pelabelan volum SELinux stabil dalam v1.36. Untuk volum yang disokong, sistem boleh menggunakan konteks lekapan dan bukannya melabel semula setiap fail secara rekursif. Ini biasanya mengurangkan kerja permulaan untuk volum yang besar, tetapi andaian bahawa volum kongsi dilabel semula sebelum digunakan boleh gagal apabila domain keselamatan yang berbeza mengaksesnya. Lekapan yang berjaya tidak membuktikan bahawa aplikasi boleh membaca dan menulis.
3. Semak sempadan pemacu dan dasar
Bagi setiap pemacu CSI, sahkan sokongan untuk konteks lekapan, tingkah laku sistem fail dan sekatan pilihan lekapan. Semak dokumentasi versi yang digunakan untuk seLinuxChangePolicy, feature gates berkaitan dan tetapan lalai; jangan salin medan atau bertukar daripada keluaran lama tanpa pengesahan. Dasar kemasukan (admission policy) harus menyekat keistimewaan yang tidak perlu, menentukan domain keselamatan volum kongsi dan mengaudit perubahan.
4. Jalankan perbandingan yang boleh dihasilkan semula
Sediakan Pod ujian dengan imej, UID/GID, securityContext dan data volum yang sama. Rangkumi Pod tunggal, perkongsian domain yang sama, perkongsian privileged dan unprivileged, volum kosong dan volum yang mengandungi banyak fail. Sahkan konteks lekapan, label fail, baca dan tulis, pemulihan mulakan semula, pembesaran (expansion) dan sambungan semula CSI. Ukur setiap selang dari penciptaan Pod hingga Ready.
5. Tambah guardrail canary
Cipta kumpulan nod khusus dan set kecil CSI StorageClasses, serta mulakan dengan tugas yang boleh dicuba semula (retryable jobs). Jangan berikan kombinasi domain keselamatan yang belum disahkan volum kongsi yang sama semasa canary. Tetapkan ambang untuk log penafian, kegagalan lekapan, ralat kebenaran aplikasi, kependaman permulaan dan kejayaan mulakan semula. Hentikan pengembangan apabila guardrail dicetuskan; jangan sembunyikan isu dengan meluaskan SELinux atau keistimewaan.
6. Kendalikan risiko volum kongsi
Apabila volum dikongsi oleh Pod privileged dan unprivileged, pisahkan volum terlebih dahulu atau satukan domain keselamatan sebelum meneruskan. Untuk perkongsian yang tidak dapat dielakkan, tentukan siapa yang memiliki pelabelan, bila volum dilekapkan dan bagaimana ia ditebus guna, kemudian sahkan matriks capaian sebenar. Padamkan volum lama hanya selepas pemulihan aplikasi terbukti, supaya masalah pelabelan tidak disalah anggap sebagai kehilangan data.
7. Kekalkan bukti rollback
Rollback bermula dengan menghalang Pod baharu daripada memasuki kumpulan canary sambil mengekalkan tugas dan peristiwa yang sedang berjalan. Kemudian pilih dasar rekursif yang disokong secara eksplisit atau kumpulan nod yang lebih lama untuk versi yang digunakan. Simpan tetapan feature-gate, label nod, konfigurasi CSI, manifes Pod dan log penafian AVC SELinux. Jalankan semula perbandingan yang sama selepas rollback; arahan deployment yang berjaya semata-mata bukanlah bukti pemulihan.
Jawapan model
Saya akan menyusun migrasi ini mengikut fasa inventori, perbandingan, canary dan rollback. Hanya nod Linux dengan SELinux yang tersedia dalam mod enforcing berada dalam skop, dan sokongan pemacu CSI mesti disemak terhadap versi Kubernetes yang digunakan. v1.36 menggunakan konteks lekapan untuk volum yang disokong, mengurangkan pelabelan semula rekursif tetapi memerlukan ujian terfokus untuk volum kongsi dan domain keselamatan yang berbeza. Ujian meliputi volum kosong dan besar, satu Pod, perkongsian domain yang sama dan perkongsian privileged/unprivileged; ia membandingkan label, capaian, log penafian, kependaman permulaan dan pemulihan mulakan semula. Kumpulan canary hanya menerima kerja yang boleh dicuba semula. Ambang yang gagal akan menghentikan pengembangan, mengekalkan bukti dan mengembalikan kerja baharu ke laluan disokong yang didokumenkan.
Kesilapan biasa
- Menganggap setiap nod sebagai nod SELinux → skop impak menjadi salah → asingkan mengikut mod nod dan keadaan enforcing.
- Menguji kejayaan pelekapan sahaja → capaian masa jalan (runtime) masih dinafikan → uji identiti sebenar, label, baca, tulis dan mulakan semula.
- Meluaskan keistimewaan dengan serta-merta → sempadan keselamatan mengembang → betulkan domain keselamatan, hubungan perkongsian atau konfigurasi pemacu.
- Mengabaikan perbezaan CSI → satu kelas volum gagal dalam canary → buat matriks pemacu, sistem fail dan jenis volum.
- Memadam setiap Pod semasa rollback → bukti hilang dan tugas terhenti → bekukan trafik baharu serta kekalkan keadaan dan log.
Soalan susulan dan jawapan
Adakah mod permissive memerlukan migrasi yang sama?
Ia masih wajar diinventori dan diuji kerana mod permissive merekodkan penafian tanpa menguatkuasakannya secara normal. Ia tidak mewakili tingkah laku enforcing, jadi kriteria pelepasan mesti dihasilkan semula pada nod enforcing.
Bagaimanakah anda memisahkan isu pelabelan daripada isu CSI?
Kekalkan nod, imej dan konteks keselamatan sementara menukar jenis volum atau pemacu. Bandingkan peristiwa lekapan, penafian kernel, label fail dan log CSI. Sandarkan isu tersebut kepada laluan konteks keselamatan hanya apabila ia berulang merentasi pelbagai pemacu.
Adakah permulaan yang lebih pantas mencukupi untuk membuktikan kejayaan?
Tidak. Prestasi hanyalah satu isyarat. Matriks capaian untuk domain yang berbeza, pemulihan mulakan semula, pembesaran, tingkah laku penyambungan semula dan bukti audit juga mesti memenuhi kriteria pelepasan.
Bagaimana jika volum kongsi tidak boleh menggunakan satu domain keselamatan?
Lebih baik mengasingkan volum atau menggunakan laluan pertukaran data yang eksplisit. Jika perkongsian tidak dapat dielakkan, platform harus memiliki keputusan domain keselamatan dan kitaran hayat, dan gabungan Pod yang dibenarkan mesti dikuatkuasakan dan diuji secara regresi.