Wawancara Backend: Bagaimana Kubernetes melindungi Kubelet API dengan otorisasi terperinci (fine-grained)?

Perintah dan konteks

Tim platform harus mengizinkan kube-apiserver membaca metrik node tanpa memberikan identitas yang sama akses ke endpoint debug atau exec Kubelet. Kluster sedang ditingkatkan dari perilaku otorisasi kasar (coarse) ke Kubernetes v1.36, tanpa pemadaman pemantauan, tanpa ekspansi hak istimewa tingkat node, dan dengan bukti yang dapat diaudit. Jelaskan jalur autentikasi, atribut otorisasi, migrasi, rollback, dan metrik validasi.

Apa yang dievaluasi oleh pewawancara

• Memisahkan autentikasi endpoint HTTPS Kubelet dari otorisasi, alih-alih hanya membahas RBAC.
• Mengekspresikan prinsip hak istimewa terendah (least privilege) dengan atribut verb, resource, subresource, node, dan namespace.
• Memahami bahwa identitas klien Kubelet milik API Server memerlukan aturan otorisasi eksplisit.
• Merancang kompatibilitas migrasi, perilaku fail-closed, auditabilitas, dan rollback.

Pertanyaan klarifikasi yang perlu diajukan

1. Penelepon (caller) mana yang membutuhkan Kubelet API: hanya API Server, agen pemantauan, atau operator yang terhubung langsung ke node?
2. Kemampuan apa saja yang diperlukan: metrik, log, status kontainer yang berjalan, eksekusi perintah, atau port forwarding?
3. Apakah Kubelet menggunakan sertifikat klien atau metode autentikasi lain, dan apakah callback otorisasi API Server tersedia?
4. Apakah degradasi read-only singkat dapat diterima selama peluncuran, dan berapa batas toleransi gangguan (outage budget) pemantauan?

Kerangka jawaban 30 detik

Bagi jalur menjadi tiga lapisan: TLS atau pengautentikasi lain menetapkan identitas penelepon, pengotorisasi Kubelet memetakan permintaan ke atribut, dan layanan otorisasi membuat keputusan. Terapkan aturan least privilege hanya ke endpoint node yang diperlukan, dengan mengisolasi kemampuan debug, exec, dan proxy. Lakukan migrasi dengan menginventarisasi panggilan, mengamati penolakan (denials), memperketat aturan secara bertahap, dan beralih ke penegakan penolakan (enforced denial) hanya setelah metrik dan sakelar rollback siap.

Pembahasan mendalam langkah demi langkah

1. Autentikasi, otorisasi, dan atribut permintaan

Endpoint HTTPS Kubelet pertama-tama memvalidasi sertifikat klien atau pengautentikasi yang dikonfigurasi dan memperoleh nama pengguna beserta grup. Otorisasi memetakan permintaan HTTP ke atribut Kubernetes seperti verb, resource, subresource, namespace, name, dan node. Keberhasilan autentikasi tidak berarti otorisasi diberikan; setiap endpoint memerlukan keputusan. Ketika API Server memanggil Kubelet, --kubelet-client-certificate dan kunci yang cocok mengidentifikasi prinsipal terkontrol yang harus memiliki izin eksplisit dalam sistem otorisasi.

2. Mengekspresikan least privilege dengan subresource

Perlakukan metrik, log, status kontainer, dan eksekusi debug sebagai kemampuan yang terpisah. Berikan hanya resource atau subresource node read-only yang diperlukan dan batasi cakupan node. Jangan memberikan resource wildcard atau akses nodes/proxy yang luas hanya untuk membuat pemantauan berfungsi. Berikan eksekusi perintah, port forwarding, dan endpoint debug peran terpisah berisiko tinggi yang tidak terikat pada identitas layanan biasa milik API Server.

3. Migrasi dan kompatibilitas

Bangun matriks panggilan dari log audit dan akses saat ini: identitas, jalur, verb, node target, hasil, dan versi penelepon. Setelah mengaktifkan otorisasi terperinci, jalankan fase observasi yang mencatat potensi penolakan tanpa merusak pengumpulan data, lengkapi hanya aturan yang diperlukan, dan alihkan node secara bertahap. KubeletFineGrainedAuthz sudah GA dan diaktifkan secara default di Kubernetes v1.36, tetapi peluncuran tetap harus memverifikasi default distribusi, kredensial klien API Server, dan jalur setiap komponen pemantauan.

4. Observabilitas, rollback, dan pertahanan berlapis (defense in depth)

Catat peristiwa audit untuk izin (allows) maupun penolakan (denials) beserta identitas, node, resource, dan alasannya. Pantau latensi otorisasi, tingkat penolakan, keberhasilan pengumpulan metrik, dan akses endpoint yang tidak terduga. Jika peluncuran merusak pemantauan, pertama-tama rollback izin klien atau pulihkan aturan kompatibilitas untuk sementara waktu sambil tetap menutup endpoint berisiko tinggi. Kontrol jaringan tetap harus membatasi keterjangkauan port Kubelet; otorisasi tidak menggantikan TLS, isolasi jaringan, atau perlindungan identitas node.

Jawaban model

Saya akan memverifikasi pengautentikasi endpoint Kubelet terlebih dahulu, lalu memetakan setiap permintaan ke atribut otorisasi standar. API Server menggunakan sertifikat klien yang terkontrol, dan sistem otorisasi mengevaluasi verb, resource, subresource, node, dan namespace untuk least privilege. Pengumpulan metrik hanya menerima kemampuan read-only yang diperlukan. exec, port forwarding, dan endpoint debug menggunakan peran berisiko tinggi yang terpisah; izin wildcard dan akses nodes/proxy yang luas tidak dilampirkan pada identitas biasa API Server.

Migrasi ini memiliki empat tahap: inventarisasi matriks panggilan; amati penolakan tanpa mengganggu pengumpulan data; tambahkan aturan minimal dalam kelompok node dan komponen; kemudian tegakkan penolakan dengan sakelar rollback. KubeletFineGrainedAuthz sudah GA dan diaktifkan secara default di v1.36, tetapi saya akan memverifikasi pengaturan distribusi, kredensial API Server, dan versi pemantauan. Catatan audit menyimpan identitas, node, resource, hasil, dan alasan, sementara kebijakan jaringan terus membatasi port Kubelet sehingga kontrol otorisasi, transport, dan jaringan saling melengkapi.

Kesalahan umum

• Mengonfigurasi autentikasi TLS dan berasumsi bahwa sertifikat klien memberikan akses ke setiap Kubelet API.
• Menggunakan resource wildcard atau izin nodes/proxy yang luas untuk memperbaiki pemantauan.
• Menegakkan penolakan tanpa matriks panggilan, menyebabkan kegagalan pengumpulan data secara hening (silent failure) setelah peningkatan versi.
• Menggunakan kembali satu peran berhak istimewa tinggi untuk API Server dan proses debugging operator.
• Hanya mengandalkan aturan otorisasi sambil mengabaikan eksposur port Kubelet dan peringatan audit.

Pertanyaan lanjutan dan tanggapan

Lanjutan 1: Mengapa tidak memberikan identitas pemantauan nodes/proxy secara langsung?

nodes/proxy memungkinkan akses ke endpoint node melalui API Server dan dapat mencakup lebih dari sekadar pembacaan metrik. Konfirmasikan jalur permintaan yang sebenarnya dan berikan izin resource atau subresource yang konkret. Jika batasan implementasi memerlukan akses proxy, pasangkan identitas khusus dengan pembatasan cakupan node dan peringatan audit.

Lanjutan 2: Bagaimana Anda membuktikan bahwa peningkatan versi tidak memperluas hak istimewa?

Bandingkan matriks panggilan dan keputusan otorisasi sebelum dan sesudah perubahan, dengan fokus pada verb, resource, subresource, dan cakupan node yang baru. Analisis perbedaan penolakan (denial deltas), lalu gunakan permintaan sintetis untuk membuktikan bahwa metrik tetap dapat dibaca sementara exec tetap ditolak. Jadikan pemeriksaan tersebut sebagai release gate.

Lanjutan 3: Apa yang terjadi jika layanan otorisasi tidak tersedia?

Pilih kebijakan fail-closed yang eksplisit sehingga kegagalan callback tidak menjadi izin akses. Bergantung pada toleransi bisnis, pertahankan cache read-only singkat atau jeda pengumpulan data, tetapi jangan membuka endpoint berisiko tinggi untuk memulihkan metrik. Berikan peringatan dan validasi ulang setelah callback pulih.