Temu Bual Reka Bentuk Sistem: Mengurus Sijil Beban Kerja dengan Kubernetes PodCertificateRequest

Maklumat dan konteks

Dalam kluster Kubernetes berbilang penyewa, perkhidmatan mesti menggunakan mTLS untuk memanggil API dalaman. Aplikasi boleh membaca fail, tetapi tidak boleh memanggil Kubernetes API atau membawa kunci peribadi jangka panjang dalam imejnya. Reka bentuk laluan PodCertificateRequest yang lengkap untuk meminta, menandatangani, mengunjurkan, memutar, membatalkan, dan mengaudit sijil.

Perkara yang dinilai oleh penemu bual

• Sama ada anda memisahkan PodCertificateRequest, CertificateSigningRequest tradisional, dan tanggungjawab penandatangan (signer).
• Sama ada anda boleh menerangkan cara volum unjuran kubelet mengasingkan kunci, sijil, dan punca kepercayaan (trust roots).
• Sama ada anda mengendalikan kebenaran penandatangan, sempadan penyewa, tetingkap putaran, pemadaman Pod, dan kompromi nod.
• Sama ada anda menyedari bahawa PodCertificateRequest adalah beta dan dinyahdayakan secara lalai dalam v1.35, dengan pengaktifan eksplisit diperlukan dalam v1.36.

Soalan penjelasan untuk ditanya

1. Adakah sijil untuk pengesahan klien, pengesahan pelayan, atau mTLS bersama?
2. SAN, jangka hayat, punca kepercayaan, dan semantik pembatalan yang manakah diperlukan?
3. Adakah versi kluster, feature gate, konfigurasi masa jalan, dan kubelet menyokong unjuran sijil Pod?
4. Bolehkah aplikasi membuka semula fail atau memerhati perubahan direktori sebelum sijilnya tamat tempoh?

Rangka kerja jawapan 30 saat

Saya akan membenarkan kubelet meminta sijil bagi pihak Pod. Penandatangan hanya akan menerima penandatangan yang dibenarkan dan medan identiti yang terhad, kemudian menghantar kunci, sijil, dan punca kepercayaan melalui volum unjuran baca sahaja. Aplikasi akan membaca fail dan bukannya memanggil API serta memuat semula fail tersebut semasa putaran. Permintaan, pengeluaran, unjuran, dan penyegaran boleh diaudit; kegagalan akan mengekalkan sijil lama yang masih sah atau menyekat sambungan baharu. Disebabkan PodCertificateRequest adalah beta dan dinyahdayakan secara lalai dalam v1.35, serta memerlukan feature gate dan konfigurasi masa jalan dalam v1.36, saya akan bermula dengan pengesanan keupayaan dan canari kolam nod.

Perbincangan terperinci langkah demi langkah

1. Tentukan sempadan identiti dan kebenaran

Pod mengisytiharkan tujuan dan sasaran penandatangan, tetapi tidak boleh memilih CA sewenang-wenangnya. Dasar kemasukan (admission policy) mengikat namespace, service account, label Pod, dan penandatangan yang dibenarkan; penandatangan mengesahkan punca permintaan, templat SAN, dan algoritma kunci, serta menolak subjek rentas penyewa. Akses API kekal dengan kubelet dan komponen satah kawalan manakala aplikasi hanya menerima akses baca fail.

2. Reka bentuk laluan permintaan dan unjuran

Kubelet mencipta permintaan Pod dan memperoleh hasil yang ditandatangani. Kunci peribadi dijana pada nod supaya ia tidak pernah memasuki imej atau API perniagaan. Sijil, kunci, dan himpunan kepercayaan dilekapkan secara berasingan dengan kebenaran keistimewaan paling rendah. Unjuran menggunakan penggantian atomik supaya aplikasi tidak dapat melihat fail yang ditulis separa. Nama penandatangan, jangka hayat, dan SAN direkodkan sebagai atribut audit.

3. Mengendalikan putaran, pembatalan, dan kegagalan

Segarkan semula sebelum tamat tempoh dan tangani permulaan semula kubelet, kehilangan rangkaian, dan gangguan CA sementara. Kekalkan sijil lama sehingga rantai baharu disahkan; apabila pemuatan gagal, tolak sambungan baharu dan dedahkan isyarat kesihatan. Alih keluar unjuran selepas pemadaman Pod, perubahan service-account, atau kitar semula nod. Pembatalan bergantung pada kontrak CA, seperti CRL, OCSP, atau jangka hayat pendek; Kubernetes tidak menyediakan satu tingkah laku pembatalan universal untuk setiap penandatangan.

4. Rancang versi dan kebolehcerapan

Sahkan status mati secara lalai beta v1.35, feature gate dan konfigurasi masa jalan v1.36, serta matriks keserasian penandatangan-kubelet sebelum penggunaan. Pantau kependaman permintaan, kegagalan pengeluaran, baki jangka hayat, kejayaan putaran, ralat kebenaran, dan SAN yang tidak dijangka. Log harus mengandungi UID permintaan, namespace, Pod, penandatangan, dan hasil, tidak sekali-kali kunci peribadi atau kandungan sijil penuh. Kekalkan laluan unjuran legasi jangka pendek dan suis pengunduran semasa canari.

Contoh jawapan berkualiti tinggi

Saya akan menganggap sijil Pod sebagai kelayakan identiti jangka pendek yang diuruskan oleh kubelet. Kemasukan mengikat namespace dan service account kepada penandatangan yang dibenarkan; penandatangan mengesahkan SAN, algoritma, jangka hayat, dan sempadan penyewa. Kunci dijana pada nod, manakala sijil, kunci, dan punca kepercayaan dihantar sebagai fail unjuran baca sahaja yang berasingan. Aplikasi tidak pernah memanggil API: ia memerhati direktori atau membuka semula fail bagi setiap permintaan dan beralih secara atomik hanya selepas mengesahkan rantai baharu. Putaran bermula awal; gangguan sementara mengekalkan sijil lama yang masih sah, manakala penamatan tempoh atau perubahan identiti menyekat sambungan baharu dan mencetuskan amaran. Pemadaman Pod mengalih keluar unjuran, dan pembatalan mengikut kontrak penandatangan untuk jangka hayat pendek atau CRL/OCSP. Sebelum pelancaran, saya mengesahkan status mati secara lalai beta v1.35 serta feature gate dan konfigurasi masa jalan v1.36, kemudian melaksanakan canari mengikut kolam nod sambil merekodkan UID permintaan, penandatangan, kependaman, kadar kegagalan, dan baki jangka hayat.

Kesilapan lazim

• Memberikan aplikasi token Kubernetes API yang boleh mencipta CSR sewenang-wenangnya.
• Membiarkan peminta memilih mana-mana penandatangan, SAN, atau subjek rentas-namespace.
• Meletakkan kunci peribadi dalam imej, ConfigMaps, atau Secrets jangka panjang sambil mengabaikan kebenaran nod.
• Membaca sijil hanya pada permulaan dan terus menggunakan pemegang fail (file descriptor) yang telah tamat tempoh selepas putaran.
• Menganggap keupayaan beta didayakan dan stabil pada setiap versi kluster.
• Merekodkan data PEM penuh, kunci peribadi, atau medan audit sensitif penyewa ke dalam log.

Soalan susulan dan jawapan

Mengapa tidak menggunakan Secret jangka panjang?

Secret jangka panjang meningkatkan tetingkap pendedahan dan sukar untuk diikat pada identiti dan pemadaman Pod. Sijil jangka pendek dengan unjuran dan putaran kubelet mengurangkan jangka hayat kelayakan, tetapi kontrak pembatalan dan pemulihan penandatangan mesti kekal eksplisit.

Bagaimanakah anda mengehadkan nod yang dikompromi?

Hadkan akses nod kepada direktori Pod dan pengguna kontena, gunakan jangka hayat pendek dan SAN minimum, serta letakkan identiti bernilai tinggi di belakang penandatangan yang diasingkan atau dilindungi perkakasan. Pengauditan dan pengesanan sambungan luar biasa mengurangkan masa tindak balas.

Bagaimana jika feature gate dinyahdayakan?

Pastikan deployment controller mengesan sumber API, konfigurasi masa jalan, dan keupayaan kubelet. Jeda beban kerja atau beralih ke laluan legasi yang diaudit apabila prasyarat tiada; jangan sekali-kali mencipta fail secara senyap yang kelihatan sah tetapi tidak akan berputar.