Wawancara Desain Sistem: Bagaimana Anda Memigrasikan Pod Kubernetes ke User Namespace?

Prompt dan konteks yang berlaku

Sebuah kluster Kubernetes berisi image lawas yang masih berjalan sebagai UID 0 di dalam kontainer. Tim keamanan menginginkan user namespace untuk mengurangi dampak pada host akibat container escape, sementara pihak bisnis khawatir tentang kepemilikan volume, hostPath, agen pemantauan, kapabilitas privileged, dan node lama. Rancang rencana migrasi, validasi, canary, observabilitas, dan rollback.

Ini adalah pertanyaan desain sistem. Penilaiannya berfokus pada pemetaan isolasi ke identitas, penyimpanan, penjadwalan, kebijakan, dan operasi alih-alih hanya menulis hostUsers: false.

Apa yang dinilai oleh pewawancara

• Menjelaskan perbedaan antara container-root dan UID host, termasuk cakupan kapabilitas.
• Menemukan batasan di seluruh volume, host namespace, runtime CRI/OCI, dan Pod Security.
• Merancang pemeriksaan kompatibilitas dan migrasi bertahap tanpa merusak workload yang ada.
• Menentukan manfaat keamanan, biaya performa, SLO, metrik, dan kondisi rollback.
• Menangani kontra-contoh pada aplikasi, debugging, pemantauan, dan pencadangan setelah migrasi.

Kubernetes mendokumentasikan bahwa user namespace stabil dan diaktifkan secara default di v1.36; Pod memilih untuk menggunakannya dengan spec.hostUsers: false. Materi SDE II Amazon mengevaluasi desain sistem melalui keandalan, efisiensi, pengoptimalan, dan skalabilitas. Pertanyaan ini menambahkan persyaratan untuk mengukur manfaat keamanan dan risiko operasional secara bersamaan.

Pertanyaan klarifikasi

1. Apakah kluster hanya berbasis Linux, dan apakah versi kubelet, CRI, runtime OCI, serta kernel memenuhi persyaratan?
2. Apakah workload menggunakan hostNetwork, hostPID, hostIPC, hostPath, perangkat, kontainer privileged, atau agen pemantauan yang memerlukan UID host?
3. Volume mana saja yang dibagikan antar-Pod, dan apakah UID/GID file yang ada berada dalam rentang yang dapat dipetakan?
4. Apakah aplikasi benar-benar membutuhkan host root, atau hanya semantik root di dalam kontainernya?
5. Apakah tujuannya adalah penahanan escape, kepatuhan Pod Security, atau kapabilitas ber-namespace tertentu seperti administrasi jaringan lokal kontainer?
6. Bisakah Anda melakukan canary berdasarkan namespace, node pool, atau workload sambil mempertahankan template hostUsers=true untuk rollback?

Kerangka jawaban 30 detik

Bangun matriks kelayakan untuk Linux, kernel, runtime CRI/OCI, host namespace, volume, dan kapabilitas privileged. Tetapkan hostUsers: false hanya untuk Pod yang memenuhi syarat. Verifikasi bahwa semantik UID aplikasi tetap stabil sementara host melihat UID yang dipetakan dan non-privileged. Uji akses file, pemantauan, jaringan, dan debugging, lalu lakukan canary per workload. Pantau latensi startup, kesalahan izin, OOM, kontrol escape, dan SLO bisnis; beralih kembali ke template lama jika ambang batas terlampaui.

Jawaban mendalam langkah demi langkah

1. Jelaskan model isolasi

User namespace memetakan pengguna kontainer ke UID dan GID host yang berbeda. Root di dalam kontainer dapat melakukan operasi yang diperlukan di dalam namespace tersebut, tetapi kapabilitasnya hanya valid di sana dan tidak memberikan wewenang host-root. Kubernetes mengikutsertakan Pod dengan hostUsers: false dan menetapkan pemetaan host yang tidak tumpang tindih pada sebuah node.

Hal ini mengubah batasan identitas kernel; ini bukanlah sandbox yang sepenuhnya terisolasi. Tetap gunakan seccomp, AppArmor atau SELinux, kebijakan jaringan, sistem file read-only, hak akses terendah (least privilege), dan node yang telah ditambal. User namespace adalah salah satu kontrol, bukan solusi untuk setiap jalur escape.

2. Periksa kelayakan runtime dan node

Konfirmasikan dukungan user-namespace di kubelet, CRI, dan runtime OCI pada setiap node target. Dokumentasi Kubernetes mencantumkan dukungan seperti containerd 2.0, CRI-O 1.25, runc 1.2, dan crun 1.9; penerapan masih perlu memverifikasi kernel, mount idmapped, dan pengaturan distribusi.

Kebijakan admisi dapat menolak node atau kombinasi kapabilitas yang tidak memenuhi syarat. CI me-render Pod akhir dan memeriksa hostUsers, konteks keamanan, host namespace, dan jenis volume. Sebelum peluncuran, Pod probe memvalidasi pembuatan, proses mount, restart, dan penjadwalan ulang node.

3. Evaluasi volume dan UID/GID

Pod runAsUser, runAsGroup, dan fsGroup masih mendeskripsikan pengguna di dalam kontainer. Semantik izin volume harus tetap dapat digunakan seperti sebelumnya, sehingga aplikasi biasanya tidak memerlukan penulisan ulang kepemilikan secara menyeluruh hanya karena user namespace diaktifkan.

File di luar rentang UID/GID yang dipetakan dapat muncul sebagai ID overflow dan mungkin tidak dapat ditulisi. Pindai pemilik, skrip init, volume bersama, dan alat pencadangan/pemulihan sebelum migrasi. Perbaiki image atau data sebelum mengaktifkan user namespace untuk workload tersebut.

4. Tangani kombinasi terlarang dan kebijakan

Dengan user namespace diaktifkan, Pod tidak dapat menggunakan host namespace tertentu seperti hostNetwork, hostPID, atau hostIPC. Workload yang memerlukan perangkat host, mode privileged, atau mount proc khusus memerlukan tinjauan terpisah. Pod Security Standards dapat melonggarkan pemeriksaan tertentu secara terkontrol, tetapi itu bukan izin untuk menghapus setiap kebijakan lainnya.

Tandai workload yang bergantung pada host-namespace sebagai ditangguhkan dan catat persetujuan pengecualian, kontrol kompensasi, serta masa berlakunya. Jangan menghapus field secara otomatis hanya untuk lolos admisi; hal itu mengubah kegagalan fungsional menjadi penurunan tingkat keamanan yang tidak terlihat.

5. Rancang performa, SLO, dan observabilitas

Lacak latensi startup Pod dan mount volume, CPU serta memori node, kesalahan izin di dalam kontainer, hilangnya pemantauan, keberhasilan pencadangan/pemulihan, dan restart. Mount idmapped dapat menghindari chown rekursif pada volume besar, tetapi lakukan pengukuran dengan kernel, runtime, dan sistem file yang sebenarnya daripada hanya mengandalkan klaim teoretis.

Beri tag pada log dan metrik dengan versi migrasi, node pool, image, dan jenis volume. Sinyal keamanan mencakup uji escape yang ditolak, operasi privileged yang gagal, dan pelanggaran Pod Security; sinyal bisnis mencakup kesalahan permintaan, latensi, dan integritas data.

6. Lakukan migrasi bertahap dan rollback

Mulai dengan workload stateless yang tidak menggunakan host namespace dan memiliki volume sederhana, lalu perluas ke layanan stateful. Simpan hash dari template hostUsers=true untuk setiap batch. Hentikan secara otomatis jika terjadi kesalahan izin, kemunduran waktu startup, peningkatan rasio kesalahan bisnis, kegagalan baca/tulis volume, atau penggusuran (eviction) node.

Rollback mengubah lebih dari satu field: verifikasi bahwa mount volume, pengguna runAs, agen pemantauan, dan output admisi kembali ke bentuk semula. Hindari memperbarui runtime, kernel, dan image dalam jendela waktu yang sama agar penyebab kegagalan tetap dapat diidentifikasi.

7. Nyatakan manfaat keamanan dan risiko residual

User namespace mengurangi dampak host dari container-root escape dan menyediakan domain yang lebih sempit untuk workload yang membutuhkan administrasi lokal kontainer. Fitur ini tidak melindungi rahasia aplikasi, serangan logika lintas-kontainer, kebijakan jaringan yang buruk, atau layanan bersama yang telah disusupi.

Tinjauan keamanan harus mencantumkan hostPath, perangkat, kapabilitas, antarmuka kernel, dan service account yang tersisa, kemudian menggabungkan seccomp, SELinux, isolasi node, serta penambalan kerentanan ke dalam defense-in-depth.

Contoh jawaban berkualitas tinggi

Saya akan membangun matriks kelayakan: node target harus berupa Linux dan memenuhi persyaratan user-namespace untuk kubelet, runtime CRI/OCI, kernel, dan sistem file. Saya akan mengecualikan Pod yang menggunakan hostNetwork, hostPID, hostIPC, perangkat privileged, atau asumsi UID host. Template yang memenuhi syarat menetapkan hostUsers: false; pengujian mengonfirmasi semantik UID/GID kontainer tetap benar sementara host melihat pemetaan non-privileged.

Sebelum peluncuran, saya akan memindai pemilik volume, skrip init, volume bersama, dan jalur pencadangan/pemulihan, termasuk perilaku overflow-ID. Pod probe memverifikasi pembuatan, mount, restart, dan penjadwalan ulang. Canary mengukur latensi startup dan mount, kesalahan izin, SLO bisnis, penggusuran, pemantauan, dan sinyal pencadangan. Hash template lama tetap tersedia untuk rollback segera.

Saya akan memperlakukan user namespace sebagai salah satu lapisan defense-in-depth dan tetap mempertahankan seccomp, SELinux/AppArmor, kebijakan jaringan, least privilege, dan penambalan node. Manfaat keamanan, biaya performa, dan workload yang ditangguhkan harus masuk dalam daftar periksa migrasi; menetapkan satu field saja bukanlah keseluruhan migrasi itu sendiri.

Kesalahan umum

• Hanya menulis hostUsers: false tanpa memeriksa kondisi Linux, runtime, kernel, dan volume.
• Mengatakan root kontainer menjadi pengguna biasa dan mengabaikan dua arti UID.
• Memperlakukan user namespace sebagai solusi otomatis untuk setiap risiko escape, hak istimewa, atau jaringan.
• Melewatkan batasan hostNetwork, hostPID, hostIPC, hostPath, perangkat, dan proc mount.
• Melakukan chown secara rekursif pada setiap volume atau gagal memindai file dengan UID/GID overflow.
• Memperbarui runtime, kernel, dan image secara bersamaan, sehingga kegagalan tidak dapat diatribusikan.
• Tidak memiliki template lama, kondisi penghentian otomatis, atau rollback yang dapat diverifikasi.

Pertanyaan lanjutan dan jawabannya

Versi Kubernetes mana yang menjadikan user namespace stabil?

Dokumentasi resmi menandai fitur ini stabil dan diaktifkan secara default di Kubernetes v1.36; Pod tetap memilih untuk menggunakannya dengan spec.hostUsers: false. Verifikasi versi kluster dan node yang sebenarnya sebelum peluncuran.

Bisakah container root tetap menggunakan kapabilitas?

Kontainer root dapat menggunakan kapabilitas yang valid di dalam user namespace tersebut, tetapi kapabilitas tersebut tidak secara otomatis menjadi hak istimewa host. Terapkan least privilege, seccomp, dan kontrol LSM.

Apakah semua izin PVC yang ada akan rusak?

Semantik UID/GID kontainer biasanya tetap stabil, sehingga penulisan ulang kepemilikan secara menyeluruh tidak diperlukan. File di luar rentang pemetaan dapat menjadi overflow ID dan perlu dipindai serta diperbaiki.

Mengapa fitur ini tidak dapat digabungkan dengan hostNetwork?

User namespace bergantung pada batas pengguna dan sumber daya yang terisolasi, dan beberapa kombinasi host-namespace akan merusak isolasi tersebut, sehingga Kubernetes melarangnya. Tetapkan workload host-network sebagai pengecualian eksplisit dengan kontrol kompensasi.

Bagaimana Anda membuktikan bahwa risiko telah berkurang?

Jalankan uji isolasi escape dan operasi privileged, amati UID host, kapabilitas, dan cakupan akses, serta bandingkan kesalahan bisnis, latensi startup, dan integritas volume. Keberhasilan pembuatan Pod saja bukanlah bukti.

Workload mana yang harus menunggu?

Tangguhkan workload yang memerlukan host namespace, perangkat khusus, antarmuka kernel privileged, atau tata letak UID/GID volume yang tidak dapat diperbaiki. Catat alasannya, kontrol kompensasi, dan tanggal penilaian ulang.