Temu Duga Backend: Bagaimanakah Kubernetes melindungi Kubelet API dengan kebenaran terperinci (fine-grained)?

Prompt dan konteks

Pasukan platform mesti membenarkan kube-apiserver membaca metrik nod tanpa memberikan identiti yang sama akses ke titik akhir debug atau exec Kubelet. Kluster sedang dinaik taraf daripada tingkah laku kebenaran kasar kepada Kubernetes v1.36, tanpa gangguan pemantauan, tiada peluasan keistimewaan peringkat nod, dan bukti yang boleh diaudit. Terangkan laluan pengesahan, atribut kebenaran, migrasi, rollback dan metrik pengesahan.

Perkara yang dinilai oleh penemu duga

• Memisahkan pengesahan titik akhir HTTPS Kubelet daripada kebenaran dan bukannya hanya membincangkan RBAC.
• Menyatakan keistimewaan paling sedikit (least privilege) dengan atribut verb, resource, subresource, node dan namespace.
• Memahami bahawa identiti klien Kubelet bagi API Server memerlukan peraturan kebenaran yang jelas.
• Mereka bentuk migrasi keserasian, tingkah laku fail-closed, kebolehauditan dan rollback.

Soalan penjelasan untuk ditanya

1. Pemanggil mana yang memerlukan Kubelet API: hanya API Server, ejen pemantauan, atau pengendali yang menyambung terus ke nod?
2. Keupayaan manakah yang diperlukan: metrik, log, keadaan kontena yang sedang berjalan, pelaksanaan perintah, atau pemajuan port?
3. Adakah Kubelet menggunakan sijil klien atau kaedah pengesahan lain, dan adakah panggilan balik kebenaran API Server tersedia?
4. Adakah degradasi baca sahaja yang singkat boleh diterima semasa pelancaran, dan apakah belanjawan gangguan pemantauan?

Rangka kerja jawapan 30 saat

Bahagikan laluan kepada tiga lapisan: TLS atau pengesah lain menetapkan identiti pemanggil, pengizin Kubelet memetakan permintaan kepada atribut, dan perkhidmatan kebenaran membuat keputusan. Gunakan peraturan least privilege hanya pada titik akhir nod yang diperlukan, mengasingkan keupayaan debug, exec dan proksi. Lakukan migrasi dengan menginventori panggilan, memerhati penolakan, mengetatkan peraturan secara berperingkat, dan beralih kepada penolakan yang dikuatkuasakan hanya selepas metrik dan suis rollback sedia.

Perbincangan mendalam langkah demi langkah

1. Pengesahan, kebenaran dan atribut permintaan

Titik akhir HTTPS Kubelet terlebih dahulu mengesahkan sijil klien atau pengesah yang dikonfigurasikan dan memperoleh nama pengguna serta kumpulan. Kebenaran memetakan permintaan HTTP kepada atribut Kubernetes seperti verb, resource, subresource, namespace, name dan node. Kejayaan pengesahan tidak membayangkan kebenaran; setiap titik akhir memerlukan keputusan. Apabila API Server memanggil Kubelet, --kubelet-client-certificate dan kunci yang sepadan mengenal pasti prinsipal terkawal yang mesti mempunyai kebenaran eksplisit dalam sistem kebenaran.

2. Nyatakan least privilege dengan subresource

Anggap metrik, log, keadaan kontena dan pelaksanaan debug sebagai keupayaan yang berasingan. Berikan hanya resource atau subresource nod baca sahaja yang diperlukan dan hadkan skop nod. Jangan berikan resource wildcard atau akses nodes/proxy yang luas semata-mata untuk membolehkan pemantauan berfungsi. Berikan pelaksanaan perintah, pemajuan port dan titik akhir debug peranan berisiko tinggi yang berasingan yang tidak terikat dengan identiti perkhidmatan biasa API Server.

3. Migrasi dan keserasian

Bina matriks panggilan daripada log audit dan akses semasa: identiti, laluan, verb, nod sasaran, hasil dan versi pemanggil. Selepas mendayakan kebenaran terperinci, jalankan fasa pemerhatian yang merekodkan kemungkinan penolakan tanpa mengganggu pengumpulan data, penuhi hanya peraturan yang diperlukan, dan tukar nod secara berperingkat. KubeletFineGrainedAuthz telah mencapai status GA dan didayakan secara lalai dalam Kubernetes v1.36, tetapi pelancaran masih perlu mengesahkan tetapan lalai pengedaran, kelayakan klien API Server dan laluan setiap komponen pemantauan.

4. Kebolehlihatan, rollback dan pertahanan mendalam (defense in depth)

Rekod peristiwa audit untuk kedua-dua kebenaran (allows) dan penolakan (denials) berserta identiti, nod, resource dan sebab. Pantau kependaman kebenaran, kadar penolakan, kejayaan pengumpulan metrik dan akses titik akhir yang tidak dijangka. Jika pelancaran mengganggu pemantauan, undurkan kebenaran klien terlebih dahulu atau pulihkan peraturan keserasian buat sementara waktu sambil memastikan titik akhir berisiko tinggi ditutup. Kawalan rangkaian masih mesti mengehadkan kebolehcapaian port Kubelet; kebenaran tidak menggantikan TLS, pengasingan rangkaian, atau perlindungan identiti nod.

Model jawapan

Saya akan mengesahkan pengesah titik akhir Kubelet terlebih dahulu, kemudian memetakan setiap permintaan kepada atribut kebenaran standard. API Server menggunakan sijil klien terkawal, dan sistem kebenaran menilai verb, resource, subresource, node dan namespace untuk least privilege. Pengumpulan metrik hanya menerima keupayaan baca sahaja yang diperlukan. exec, pemajuan port dan titik akhir debug menggunakan peranan berisiko tinggi yang berasingan; kebenaran wildcard dan akses nodes/proxy yang luas tidak dilampirkan pada identiti biasa API Server.

Migrasi ini mempunyai empat peringkat: inventori matriks panggilan; perhatikan penolakan tanpa mengganggu pengumpulan data; tambah peraturan minimum dalam kelompok nod dan komponen; kemudian kuat kuasakan penolakan dengan suis rollback. KubeletFineGrainedAuthz telah GA dan didayakan secara lalai dalam v1.36, tetapi saya akan mengesahkan tetapan pengedaran, kelayakan API Server dan versi pemantauan. Rekod audit mengekalkan identiti, nod, resource, hasil dan sebab, manakala dasar rangkaian terus menyekat port Kubelet supaya kawalan kebenaran, pengangkutan dan rangkaian saling melengkapi.

Kesilapan biasa

• Mengkonfigurasi pengesahan TLS dan menganggap sijil klien membenarkan setiap Kubelet API.
• Menggunakan resource wildcard atau kebenaran nodes/proxy yang luas untuk membetulkan pemantauan.
• Menguatkuasakan penolakan tanpa matriks panggilan, menyebabkan kegagalan pengumpulan data secara senyap selepas naik taraf.
• Menggunakan semula satu peranan berkeistimewaan tinggi untuk API Server dan penyahpepijatan pengendali.
• Hanya bergantung pada peraturan kebenaran sambil mengabaikan pendedahan port Kubelet dan amaran audit.

Soalan susulan dan jawapan

Susulan 1: Mengapa tidak memberikan identiti pemantauan nodes/proxy secara terus?

nodes/proxy membenarkan akses ke titik akhir nod melalui API Server dan boleh meliputi lebih banyak daripada sekadar bacaan metrik. Sahkan laluan permintaan sebenar dan berikan kebenaran resource atau subresource yang konkrit. Jika kekangan pelaksanaan memerlukan akses proksi, gandingkan identiti khusus dengan pengehadan skop nod dan amaran audit.

Susulan 2: Bagaimanakah anda membuktikan bahawa peningkatan tidak memperluaskan keistimewaan?

Bandingkan matriks panggilan dan keputusan kebenaran sebelum dan selepas perubahan, dengan memfokuskan pada verb, resource, subresource dan skop nod baharu. Analisis perbezaan penolakan (denial deltas), kemudian gunakan permintaan sintetik untuk membuktikan metrik kekal boleh dibaca sementara exec kekal ditolak. Jadikan pemeriksaan tersebut sebagai release gates.

Susulan 3: Apakah yang berlaku jika perkhidmatan kebenaran tidak tersedia?

Pilih dasar fail-closed yang eksplisit supaya kegagalan panggilan balik tidak menjadi kebenaran. Bergantung pada toleransi perniagaan, kekalkan cache baca sahaja yang singkat atau jeda pengumpulan data, tetapi jangan buka titik akhir berisiko tinggi untuk memulihkan metrik. Berikan amaran dan buat pengesahan semula selepas panggilan balik pulih.