Wawancara Linux: Bagaimana Container Mengisolasi Proses dan Sumber Daya?

Prompt dan Konteks yang Berlaku

Pada host Linux yang menggunakan cgroup v2, container A memiliki batasan latihan berikut:

Di dalam container, aplikasi melihat dirinya sebagai PID 1, memiliki hostname container, tabel mount-nya sendiri, dan antarmuka jaringannya sendiri. Jelaskan bagaimana runtime membuat lingkungan tersebut, dari mana isolasi sebenarnya berasal, dan bagaimana kegagalan limit muncul. Kemudian bahas batasan keamanan shared-kernel dan buktikan konfigurasi tersebut dengan status kernel yang dapat diamati alih-alih hanya mengandalkan docker run yang berhasil.

Pertanyaan ini berlaku untuk peran Linux, platform, SRE, DevOps, infrastruktur, cloud, keamanan, dan backend. Nilai-nilai ini adalah batasan wawancara, bukan default yang direkomendasikan. "Container" mengacu pada process container bergaya OCI Linux; produk container berbasis VM menambahkan lapisan isolasi yang berbeda.

Hal yang Dievaluasi oleh Pewawancara

Ujian pertama adalah apakah kandidat dapat mengganti frasa "VM ringan" dengan model proses yang akurat. Container Linux adalah sebuah pohon proses (process tree) pada host. Namespace mengubah sumber daya global yang dapat dilihat oleh proses-proses tersebut: PID, mount, objek jaringan, objek IPC, identitas host, user ID, path cgroup, dan secara opsional clock. Root filesystem dan tampilan mount privat menyediakan image userspace. Tidak ada satu pun dari hal tersebut yang menciptakan kernel kedua.

Ujian kedua adalah memisahkan visibilitas dari kontrol sumber daya. Namespace menjawab "instance mana yang dapat diamati atau dimodifikasi oleh proses ini?" Cgroup menjawab "berapa banyak yang dapat dikonsumsi oleh grup ini, dan bagaimana perhitungannya?" Namespace PID tidak membatasi jumlah task. Batas PID cgroup tidak menyembunyikan proses host. Namespace mount mengubah tampilan mount, sedangkan rootfs menyediakan file. chroot saja bukanlah container yang lengkap maupun batasan keamanan.

Ujian ketiga adalah menalar perilaku dari file cgroup v2 yang tepat. memory.max adalah batas memori keras (hard memory boundary) yang dapat menyebabkan cgroup-local OOM kill setelah proses reclaim gagal. cpu.max adalah kontrol bandwidth: setelah mengonsumsi 50 ms dalam periode 100 ms, pekerjaan yang dapat dijalankan (runnable work) akan di-throttle sampai kuota tersedia; pekerjaan tersebut tidak dimatikan (kill). pids.max menolak fork() atau clone() yang melanggar dengan EAGAIN. Kandidat harus menyebutkan event counter yang membedakan hasil-hasil ini.

Ujian keempat adalah penilaian keamanan (security judgment). Container berbagi kernel host, sehingga namespace dan cgroup tidak sama dengan batasan VM. Pemetaan user-ID, set capability yang minimal, no_new_privs, seccomp, LSM seperti AppArmor atau SELinux, mount read-only atau masked, dan perangkat yang dibatasi mengurangi attack surface. Container privileged, namespace PID atau jaringan host, Docker socket, atau mount host yang luas dapat dengan sengaja menghapus batasan-batasan penting.

Terakhir, pewawancara menginginkan rencana verifikasi. Jawabannya harus membandingkan identitas inode namespace, pemetaan UID/GID, keanggotaan cgroup dan file controller, capability proses, status seccomp, propagasi mount, antarmuka jaringan, dan counter kegagalan dari kedua sisi batasan.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Runtime dan mode container mana yang berada dalam cakupan? Diasumsikan OCI runtime pada Linux. Mode rootless, pemetaan ulang user-namespace, mode privileged, dan sandbox berbasis VM mengubah batasan kepercayaan (trust boundary).
• Apakah "0,5 CPU" berarti kuota atau bobot relatif? Di sini artinya batas bandwidth 50.000 mikrodetik per periode 100.000 mikrodetik. cpu.weight hanya mengubah bagian relatif selama terjadi contention.
• Apa saja yang termasuk dalam 512 MiB? cgroup v2 memperhitungkan pengguna utama seperti anonymous memory, page cache, struktur kernel, dan buffer socket, tetapi tidak semua sumber daya host dikontrol oleh file tunggal ini.
• Apakah 128 berarti proses atau task kernel? Controller pids menggunakan ID task kernel, sehingga thread juga mengonsumsi anggaran tersebut. Detail ini penting untuk runtime yang menggunakan banyak thread.
• Apakah swap diaktifkan dan dibatasi secara terpisah? memory.max dan memory.swap.max adalah kontrol yang berbeda. Prompt hanya menetapkan batas memori, sehingga kebijakan swap harus diperiksa, bukan diasumsikan.
• Namespace mana yang sebenarnya dikonfigurasi? Konfigurasi OCI dapat membuat namespace baru, bergabung dengan namespace yang ada berdasarkan path, atau menghilangkan jenis tersebut dan mewarisi namespace runtime. Kehilangan salah satunya adalah perubahan batasan yang nyata.
• Apa model ancamannya (threat model)? Beban kerja multi-tenant yang bermusuhan mungkin memerlukan batasan VM atau microVM selain isolasi proses. Beban kerja internal tepercaya dapat menerima keseimbangan yang berbeda.

Kerangka Jawaban 30 Detik

"Container Linux adalah pohon proses host yang dimulai terhadap rootfs, ditempatkan dalam namespace dan cgroup terpilih; kernel host tetap dibagikan. Namespace mengisolasi tampilan, sementara cgroup memperhitungkan dan membatasi konsumsi. Di sini, memory.max=536870912 dapat menyebabkan cgroup OOM setelah reclaim gagal, cpu.max=50000 100000 men-throttle pekerjaan kelas-fair setelah 50 ms per 100 ms, dan pids.max=128 menolak fork atau clone yang melanggar dengan EAGAIN.

Saya akan menambahkan pemetaan UID jika sesuai, capability minimal, no_new_privs, seccomp, kebijakan AppArmor atau SELinux, mount yang aman, dan pembatasan device. Saya akan memverifikasi identitas namespace, pemetaan UID, mount, antarmuka, file cgroup efektif, capability, dan status keamanan dari kedua sisi, kemudian menjalankan pengujian berbatas dan memerlukan bukti memory.events, cpu.stat, dan pids.events yang sesuai."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Mulai dengan Model Proses Host

Runtime menerima OCI bundle yang berisi root filesystem dan konfigurasi. Urutan penyiapan yang representatif adalah:

1. memvalidasi bundle, executable, mount, pilihan namespace, kredensial, dan pengaturan sumber daya;
2. membuat atau memilih subtree cgroup dan menulis nilai controller;
3. membuat namespace baru atau bergabung dengan namespace yang dikonfigurasi;
4. menetapkan pemetaan UID/GID jika user namespace digunakan;
5. membuat propagasi mount aman, me-mount rootfs dan filesystem khusus, serta mengalihkan root proses;
6. membuat atau memindahkan perangkat jaringan dan mengonfigurasi rute saat network namespace baru digunakan;
7. mengatur kredensial, capability, no_new_privs, seccomp, dan label atau profil LSM;
8. melampirkan proses ke cgroup dan menjalankan exec pada aplikasi yang dikonfigurasi.

Urutan persis dan proses pembantu bervariasi menurut runtime. Invariannya adalah status kernel yang dapat diamati: aplikasi tetap menjadi proses yang dijadwalkan host dengan keanggotaan namespace, kredensial, mount, filter, dan path cgroup. Jika runtime crash setelah penyiapan parsial, pembersihan harus menghapus mount, antarmuka, pin namespace, dan cgroup; kata "container" bukanlah objek kernel yang melakukan pembersihan secara otomatis.

Langkah 2: Berikan Satu Tanggung Jawab untuk Setiap Namespace

Namespace utama saling melengkapi:

Jenis namespace yang dihilangkan dari daftar namespace OCI akan diwarisi dari runtime. --pid=host, jaringan host, atau bergabung dengan namespace container lain dapat disengaja, tetapi jawabannya harus menyebutkan hilangnya isolasi tersebut daripada tetap mendeskripsikannya sebagai container yang sepenuhnya privat.

Batasan filesystem membutuhkan namespace mount dan rootfs. Mode propagasi privat atau slave mencegah event mount container mengalir secara tak terduga ke host. Mount read-only, masked path, /dev minimal, dan bind mount eksplisit mempersempit akses. Bind mount yang dapat ditulisi (writable) dari root host atau socket engine container menciptakan jalur langsung berdampak tinggi terlepas dari hostname privat proses tersebut.

Langkah 3: Menalar Hasil dari Tiga Batas Sumber Daya

Memori. memory.max=536870912 adalah batas keras utama untuk cgroup dan turunannya. Saat penggunaan mendekati batas, kernel mencoba melakukan reclaim. Jika penggunaan mencapai batas dan tidak dapat dikurangi, cgroup memasuki penanganan OOM; dalam mode default OOM killer dapat memilih task dalam cgroup tersebut, dan memory.oom.group=1 dapat meminta perlakuan sebagai satu beban kerja yang tidak dapat dibagi. Pembacaan singkat di atas batas dapat terjadi. Periksa memory.current, memory.peak, dan field max, oom, oom_kill, serta oom_group_kill di memory.events. Jangan mendiagnosis setiap SIGKILL sebagai OOM cgroup tanpa counter tersebut dan bukti kernel atau runtime.

CPU. cpu.max=50000 100000 berarti bahwa task kelas-fair dalam grup dapat mengonsumsi hingga 50.000 mikrodetik selama setiap periode 100.000 mikrodetik: bandwidth rata-rata 0,5 CPU. Beberapa thread dapat menghabiskan kuota secara bersamaan dan menghabiskannya lebih awal dalam periode tersebut. Task yang siap berjalan (runnable) kemudian di-throttle sampai kuota tersedia; task tidak dihentikan (terminated). Periksa usage_usec, nr_periods, nr_throttled, dan throttled_usec di cpu.stat. Lonjakan latensi di dekat batas periode dapat berupa throttling kuota bahkan ketika CPU host sebenarnya tersedia.

Task. pids.max=128 adalah batas keras hierarkis pada task kernel. Thread juga dihitung. Begitu task baru akan melanggar kebijakan, fork() atau clone() gagal dengan EAGAIN; task yang ada tetap berjalan. Periksa pids.current, pids.peak, dan jumlah max di pids.events. Memindahkan task yang ada atau menurunkan batas yang dikonfigurasi dapat menghasilkan pids.current > pids.max untuk sementara; pembuatan task baru tetap diblokir dari melanggar kebijakan.

Parent cgroup juga membatasi child cgroup. Child tidak dapat memperoleh kapasitas CPU, memori, atau task yang tidak diizinkan oleh ancestor-nya. Sebaliknya, ketiga pengaturan ini tidak secara otomatis membatasi setiap sumber daya: ruang penyimpanan, I/O, file descriptor, bandwidth jaringan, perangkat, dan objek global kernel memerlukan kontrol dan batas operasinya sendiri.

Langkah 4: Melapisi Kontrol Keamanan di Sekitar Kernel Bersama

User namespace memungkinkan sebuah proses menjadi UID 0 di dalam sambil memetakan ke UID unprivileged normal di luar. Hal ini mengurangi dampak dari namespace escape atau akses file host yang salah, tetapi pemetaan dan kepemilikan filesystem harus dirancang bersama. Tanpa user namespace, root di dalam container tetaplah UID 0 host, meskipun capability dan objek yang dapat diaksesnya dibatasi.

Capability membagi hak istimewa root tradisional. Mulailah dari set minimum alih-alih memberikan semua capability. Menghapus capability hanya berguna jika proses tidak dapat memperolehnya kembali melalui file capability, eksekusi set-user-ID, atau jalur lain; set yang dibatasi dan no_new_privs membuat tujuan tersebut dapat diaudit.

Seccomp memfilter system call dan dapat mengizinkan, menolak, menjebak (trap), mematikan (kill), mencatat (log), atau memberi tahu (notify) berdasarkan pemanggilan dan argumen. Ini mengurangi attack surface kernel yang dapat dijangkau tetapi tidak memahami otorisasi tingkat aplikasi. LSM seperti AppArmor atau SELinux menerapkan kebijakan pada operasi file, proses, socket, dan objek lainnya. Filesystem read-only, masked path /proc, dan set perangkat minimal menambahkan batasan independen.

Ini adalah lapisan, bukan pengganti. Cgroup terutama menangani akuntansi dan resource denial of service; mereka tidak mencegah satu container membaca data container lain. Namespace terutama mengisolasi tampilan; mereka tidak menambal kernel yang dibagikan. Untuk tenant yang bermusuhan, risiko eksploitasi kernel atau kepatuhan dapat membenarkan batasan VM, microVM, atau sandboxed-kernel.

Langkah 5: Verifikasi Status Kernel dari Kedua Sisi

Dari host, pertama-tama identifikasi proses init container dan path cgroup. Sketsa inspeksi generik adalah:

pid=<host-pid-of-container-init>
cg=/sys/fs/cgroup/<container-cgroup>

readlink /proc/$pid/ns/{pid,mnt,net,uts,ipc,user,cgroup}
cat /proc/$pid/uid_map
cat /proc/$pid/gid_map
cat /proc/$pid/cgroup

cat "$cg/memory.current" "$cg/memory.max" "$cg/memory.events"
cat "$cg/cpu.max" "$cg/cpu.stat"
cat "$cg/pids.current" "$cg/pids.max" "$cg/pids.events"

grep -E '^(CapPrm|CapEff|CapBnd|NoNewPrivs|Seccomp):' /proc/$pid/status

Bandingkan identitas device/inode symlink namespace dengan host dan dengan container lain. Identitas yang berbeda membuktikan instance namespace yang berbeda; hal itu saja tidak membuktikan mount, rute, atau kebijakan yang aman. Periksa tabel mount dan propagasi yang sebenarnya, link jaringan dan rute, set capability efektif, mode seccomp, label LSM, dan node perangkat.

Di dalam container, catat /proc/1/status, /proc/self/cgroup, mount, hostname, proses yang terlihat, antarmuka, rute, UID/GID, dan link namespace. Gunakan nsenter dari host yang berwenang hanya untuk diagnosis; memasuki namespace adalah akses istimewa, bukan bukti bahwa batasannya gagal.

Terakhir, jalankan pengujian kegagalan berbatas di lingkungan sekali pakai. Alokasikan memori secara bertahap dan korelasikan kegagalan dengan memory.events; jalankan beban CPU dan korelasikan latensi dengan nr_throttled; buat thread atau proses sampai pembuatan berikutnya mengembalikan EAGAIN dan pids.events bertambah. Hentikan pengujian sebelum tekanan tingkat host terjadi, dan verifikasi bahwa sibling cgroup tetap sehat.

Langkah 6: Mengubah Pengamatan Menjadi Kriteria Penerimaan

Catatan penerimaan yang dapat dipertanggungjawabkan berisi nilai, identitas, dan hasil:

• ID namespace berbeda jika isolasi diperlukan dan cocok hanya jika pembagian sengaja dilakukan;
• pemetaan UID 0, capability efektif, NoNewPrivs, mode seccomp, dan label LSM cocok dengan model ancaman;
• propagasi mount, bind mount, masked path, writable path, dan akses perangkat cocok dengan konfigurasi OCI;
• memory.max, cpu.max, dan pids.max sama dengan 536870912, 50000 100000, dan 128 pada cgroup efektif;
• tekanan memori mengubah counter event memori yang relevan, beban CPU meningkatkan counter throttling tanpa mematikan task, dan pembuatan task ke-129 ditolak ketika 128 task telah dibebankan;
• parent dan sibling cgroup tetap berada dalam anggaran mereka masing-masing selama setiap pengujian;
• pengujian restart dan forced-failure tidak meninggalkan mount, antarmuka, pin namespace, atau cgroup yang terisi secara tak terduga.

Pernyataan task ke-129 bersyarat pada tepat 128 task yang telah dibebankan ke hierarki efektif dan tidak ada proses keluar yang bersamaan. Dalam pengujian nyata, baca pids.current tepat sebelum pembuatan daripada berasumsi bahwa aplikasi hanya memiliki satu task.

Contoh Jawaban yang Kuat

"Saya akan mulai dengan model proses host. Runtime mengambil OCI rootfs dan config, membuat atau bergabung dengan namespace PID, mount, network, UTS, IPC, user, cgroup, dan time yang diminta, mengonfigurasi mount dan jaringan, melampirkan pohon proses ke cgroup, menerapkan kredensial dan kebijakan keamanan, serta mengeksekusi (exec) aplikasi. PID 1 di dalam tetap merupakan proses host dengan PID lain di luar. Container memiliki tampilan userspace privat, sedangkan kernel host tetap dibagikan.

Namespace dan cgroup memecahkan masalah yang berbeda. Namespace PID mengubah visibilitas proses; namespace mount ditambah rootfs mengubah filesystem yang terlihat; namespace jaringan menyediakan antarmuka, rute, port, dan socket-nya sendiri. User namespace dapat memetakan UID 0 internal ke UID host unprivileged. Cgroup memperhitungkan dan mengontrol pohon proses tetapi tidak menyembunyikan objek host.

Untuk nilai cgroup v2 yang disebutkan, memory.max=536870912 adalah batas keras 512 MiB. Kernel mencoba reclaim, kemudian dapat memanggil penanganan OOM cgroup jika penggunaan tidak dapat dikurangi; Saya akan membaca memory.events untuk membedakan max, oom, dan oom_kill. cpu.max=50000 100000 menyediakan paling banyak 50 ms per 100 ms untuk pekerjaan kelas-fair. Begitu kuota digunakan, task yang siap berjalan akan di-throttle sampai lebih banyak kuota tersedia, dan cpu.stat melaporkan nr_throttled serta throttled_usec; tidak ada proses kill akibat batas CPU. pids.max=128 menghitung task kernel, termasuk thread. Fork atau clone yang melanggar akan mengembalikan EAGAIN, dan pids.events mencatat hit tersebut.

Karena kernel dibagikan, saya akan melapisi user namespace jika sesuai, set capability minimal, no_new_privs, seccomp, kebijakan AppArmor atau SELinux, mount read-only atau masked, dan set perangkat minimal. Saya akan menolak mode privileged, namespace host, mount host yang luas, atau akses engine-socket kecuali masing-masing merupakan persyaratan tepercaya yang eksplisit. Multi-tenancy yang bermusuhan mungkin memerlukan batasan VM atau microVM.

Untuk memverifikasi, saya akan membandingkan identitas device/inode /proc/{PID}/ns/*, peta UID/GID, mount, antarmuka, path cgroup, file controller efektif, capability, mode seccomp, dan label LSM dari host dan container. Kemudian saya akan menjalankan pengujian memori, CPU, dan task yang berbatas serta memeriksa kesesuaian counter kernel dan mode kegagalannya. Container yang sekadar berhasil berjalan belum membuktikan isolasi."

Kesalahan Umum dan Perbaikan

• Menyebut container sebagai VM kecil → ini menyembunyikan kernel bersama dan menghasilkan asumsi keamanan yang salah → jelaskan proses host dengan status namespace, cgroup, filesystem, kredensial, dan kebijakan.
• Mengatakan namespace membatasi CPU dan memori → namespace mengisolasi tampilan, bukan konsumsi → petakan batas sumber daya ke controller dan file cgroup.
• Mengatakan cgroup mengisolasi file dan proses → cgroup mengelompokkan, memperhitungkan, dan membatasi task → petakan visibilitas ke namespace PID dan mount.
• Memperlakukan chroot sebagai container → mengubah root semu tidak menambahkan isolasi PID, jaringan, user, atau sumber daya → gabungkan rootfs dengan mount dan namespace lain yang diperlukan ditambah kebijakan.
• Mengklaim batas CPU mematikan proses → kuota CPU biasanya men-throttle pekerjaan kelas-fair yang siap berjalan → periksa cpu.stat untuk throttling.
• Mengharapkan penggunaan memori berhenti tepat pada 512 MiB → reclaim, waktu akuntansi, dan kelebihan sementara memperumit pembacaan instan → gunakan memory.max dan event counter untuk memastikan hasil penegakan.
• Hanya menghitung proses terhadap pids.max → controller menghitung task kernel, sehingga thread juga mengonsumsinya → periksa pids.current sebelum pengujian limit.
• Mengasumsikan root di dalam tidak berbahaya → tanpa user namespace, itu mungkin masih berupa UID 0 host, yang hanya dibatasi oleh kontrol lain → periksa uid_map dan capability.
• Menyamakan pemisahan namespace dengan batasan tenant yang aman → kerentanan kernel atau mount host yang berbahaya dapat menembus batasan proses → nyatakan model ancaman dan tambahkan kebijakan atau batasan VM.
• Memeriksa konfigurasi tetapi bukan status efektif → flag runtime dapat ditimpa, diwarisi, atau gagal sebagian → baca /proc dan file cgroup, lalu uji setiap limit.

Pertanyaan Lanjutan

Lanjutan 1: Mengapa PID 1 Membutuhkan Perlakuan Khusus di Dalam Container?

Proses pertama dalam namespace PID terlihat sebagai PID 1 bagi keturunannya. Proses ini mengadopsi proses yatim (orphaned children) dan harus me-reap mereka, atau proses zombi akan menumpuk dan menghabiskan anggaran pids. PID 1 juga memiliki semantik penanganan sinyal khusus, sehingga pembungkus (wrapper) yang tidak meneruskan sinyal dapat membuat penghentian yang anggun (graceful termination) gagal. Verifikasi proses init yang sebenarnya, child reaping, penerusan sinyal, dan batas waktu shutdown daripada berasumsi bahwa framework aplikasi menanganinya.

Lanjutan 2: Apa Perbedaan Antara cpu.max dan cpu.weight?

cpu.max menetapkan bandwidth maksimum per periode untuk pekerjaan kelas-fair. Ini dapat men-throttle cgroup bahkan ketika host memiliki CPU yang menganggur setelah grup tersebut menghabiskan kuota saat ini. cpu.weight adalah preferensi proporsional di antara sibling cgroup yang siap berjalan selama terjadi contention dan tidak dengan sendirinya menentukan batas atas keras 0,5 CPU. Kebijakan produksi dapat menggunakan keduanya untuk tujuan yang berbeda.

Lanjutan 3: Bisakah Root Container Menjadi Unprivileged di Host?

Ya, ketika user namespace memetakan UID 0 di dalam ke rentang UID unprivileged di luar. Konfirmasikan pemetaan di /proc/{PID}/uid_map dan /proc/{PID}/gid_map. Ini mempersempit hak istimewa host, tetapi kepemilikan bind-mount, alokasi subordinate-ID, capability dalam user namespace pemilik, dan attack surface kernel masih memerlukan peninjauan.

Lanjutan 4: Mengapa Namespace Mount Privat Tidak Cukup untuk Keamanan Filesystem?

Ini mengisolasi tabel mount, tetapi runtime memutuskan filesystem dasar dan bind mount apa yang muncul di sana. Namespace privat yang berisi bind mount yang dapat ditulisi dari / masih mengekspos root host. Tinjau sumber mount, propagasi, flag writable, masked dan read-only path, node perangkat, serta kredensial proses dan kebijakan LSM secara bersamaan.

Lanjutan 5: Kapan Anda Harus Memilih VM atau MicroVM?

Pilihlah batasan yang lebih kuat ketika tenant yang saling tidak percaya mengeksekusi kode arbitrer, shared-kernel escape berada di luar risiko yang diterima, kepatuhan memerlukan kernel terpisah, atau versi kernel dan modul harus berbeda. Biayanya adalah overhead startup, memori, image, dan operasional tambahan. Keputusan ini mengikuti model ancaman dan batasan platform yang diukur, bukan label container atau VM saja.

Lanjutan 6: Bagaimana Anda Mendiagnosis Container yang Lambat tetapi Tidak Mengalami OOM-Killed?

Korelasikan latensi aplikasi dengan throttling cpu.stat, tekanan memory.events high/max, informasi pressure-stall, statistik controller I/O, penjadwalan host, dan kesalahan jaringan. Kenaikan nr_throttled atau throttled_usec dengan counter OOM yang stabil mengarah pada kuota CPU. Reclaim atau tekanan I/O juga dapat menghentikan pekerjaan tanpa proses kill, sehingga diagnosis memerlukan stempel waktu (timestamp) yang selaras dan silsilah cgroup yang efektif.