Wawancara System Design: Mengelola Sertifikat Workload dengan Kubernetes PodCertificateRequest

Konteks dan instruksi

Dalam kluster Kubernetes multi-tenant, sebuah layanan harus menggunakan mTLS untuk memanggil API internal. Aplikasi boleh membaca file, tetapi tidak boleh memanggil Kubernetes API atau membawa private key yang berumur panjang di dalam image-nya. Rancang jalur PodCertificateRequest lengkap untuk meminta, menandatangani, memproyeksikan, merotasi, mencabut, dan mengaudit sertifikat.

Hal yang dievaluasi oleh pewawancara

• Apakah Anda memisahkan PodCertificateRequest, CertificateSigningRequest tradisional, dan tanggung jawab signer.
• Apakah Anda dapat menjelaskan bagaimana projected volume kubelet mengisolasi kunci, sertifikat, dan trust root.
• Apakah Anda menangani otorisasi signer, batasan tenant, jendela rotasi, penghapusan Pod, dan kompromi node.
• Apakah Anda menyadari bahwa PodCertificateRequest berstatus beta dan dinonaktifkan secara default di v1.35, dengan pengaktifan eksplisit yang diperlukan di v1.36.

Pertanyaan klarifikasi yang perlu diajukan

1. Apakah sertifikat tersebut untuk autentikasi klien, autentikasi server, atau mutual mTLS?
2. SAN, masa berlaku, trust root, dan semantik pencabutan apa saja yang diperlukan?
3. Apakah versi kluster, feature gate, konfigurasi runtime, dan kubelet mendukung proyeksi sertifikat Pod?
4. Bisakah aplikasi membuka kembali file atau memantau perubahan direktori sebelum sertifikatnya kedaluwarsa?

Kerangka jawaban 30 detik

Saya akan membiarkan kubelet meminta sertifikat atas nama Pod. Signer hanya akan menerima signer yang berwenang dan bidang identitas yang dibatasi, kemudian mengirimkan kunci, sertifikat, dan trust root melalui projected volume read-only. Aplikasi akan membaca file alih-alih memanggil API dan memuat ulang file tersebut selama rotasi. Permintaan, penerbitan, proyeksi, dan penyegaran akan dapat diaudit; kegagalan akan mempertahankan sertifikat lama yang masih valid atau memblokir koneksi baru. Karena PodCertificateRequest berstatus beta dan dinonaktifkan secara default di v1.35, serta memerlukan feature gate dan konfigurasi runtime di v1.36, saya akan memulai dengan deteksi kemampuan dan canary node-pool.

Pembahasan mendalam langkah demi langkah

1. Tentukan batasan identitas dan otorisasi

Pod mendeklarasikan tujuan dan target signer, tetapi tidak dapat memilih CA sembarangan. Kebijakan admisi mengikat namespace, service account, label Pod, dan signer yang diizinkan; signer memvalidasi asal permintaan, templat SAN, dan algoritma kunci, menolak subjek lintas-tenant. Akses API tetap berada di tangan kubelet dan komponen control-plane sementara aplikasi hanya menerima akses baca file.

2. Rancang jalur permintaan dan proyeksi

Kubelet membuat permintaan Pod dan memperoleh hasil yang telah ditandatangani. Private key dibuat di node sehingga tidak pernah masuk ke dalam image atau API bisnis. Sertifikat, kunci, dan trust bundle di-mount secara terpisah dengan izin least-privilege. Proyeksi menggunakan penggantian atomik sehingga aplikasi tidak dapat mengamati file yang tertulis sebagian. Nama signer, masa berlaku, dan SAN dicatat sebagai atribut audit.

3. Tangani rotasi, pencabutan, dan kegagalan

Lakukan penyegaran sebelum kedaluwarsa dan antisipasi restart kubelet, kehilangan jaringan, dan pemadaman CA sementara. Pertahankan sertifikat lama sampai rantai baru tervalidasi; jika terjadi kegagalan pemuatan, tolak koneksi baru dan ekspos sinyal kesehatan. Hapus proyeksi setelah penghapusan Pod, perubahan service-account, atau daur ulang node. Pencabutan bergantung pada kontrak CA, seperti CRL, OCSP, atau masa berlaku yang pendek; Kubernetes tidak menyediakan satu perilaku pencabutan universal untuk setiap signer.

4. Rencanakan versi dan observabilitas

Verifikasi status default-off beta v1.35, feature gate serta konfigurasi runtime v1.36, dan matriks kompatibilitas signer-kubelet sebelum deployment. Pantau latensi permintaan, kegagalan penerbitan, sisa masa berlaku, keberhasilan rotasi, kesalahan izin, dan SAN yang tidak terduga. Log harus berisi UID permintaan, namespace, Pod, signer, dan hasil, tidak boleh berisi private key atau badan sertifikat lengkap. Pertahankan jalur proyeksi warisan berumur pendek dan switch rollback selama canary.

Contoh jawaban berkualitas tinggi

Saya akan memperlakukan sertifikat Pod sebagai kredensial identitas berumur pendek yang diperantarai oleh kubelet. Admisi mengikat namespace dan service account ke signer yang diizinkan; signer memvalidasi SAN, algoritma, masa berlaku, dan batasan tenant. Kunci dibuat di node, sedangkan sertifikat, kunci, dan trust root dikirimkan sebagai file proyeksi read-only yang terpisah. Aplikasi tidak pernah memanggil API: aplikasi memantau direktori atau membuka kembali file per permintaan dan beralih secara atomik hanya setelah memvalidasi rantai baru. Rotasi dimulai lebih awal; pemadaman sementara mempertahankan sertifikat lama yang masih valid, sedangkan kedaluwarsa atau perubahan identitas memblokir koneksi baru dan memunculkan peringatan. Penghapusan Pod akan menghapus proyeksi, dan pencabutan mengikuti kontrak signer untuk masa berlaku pendek atau CRL/OCSP. Sebelum peluncuran, saya memverifikasi status default-off beta v1.35 serta feature gate dan konfigurasi runtime v1.36, lalu melakukan canary berdasarkan node pool sambil mencatat UID permintaan, signer, latensi, tingkat kegagalan, dan sisa masa berlaku.

Kesalahan umum

• Memberikan token Kubernetes API kepada aplikasi yang dapat membuat CSR sembarangan.
• Membiarkan pemohon memilih sembarang signer, SAN, atau subjek lintas-namespace.
• Menaruh private key di dalam image, ConfigMap, atau Secret berumur panjang sambil mengabaikan izin node.
• Membaca sertifikat hanya saat startup dan terus menggunakan file descriptor yang kedaluwarsa setelah rotasi.
• Menganggap kapabilitas beta aktif dan stabil di setiap versi kluster.
• Mencatat data PEM lengkap, private key, atau bidang audit sensitif tenant ke dalam log.

Pertanyaan lanjutan dan jawaban

Mengapa tidak menggunakan Secret berumur panjang?

Secret yang berumur panjang meningkatkan jendela paparan risiko dan sulit diikat ke identitas serta penghapusan Pod. Sertifikat berumur pendek dengan proyeksi dan rotasi kubelet mengurangi masa berlaku kredensial, tetapi kontrak pencabutan dan pemulihan signer harus tetap eksplisit.

Bagaimana cara membatasi node yang terkompromi?

Batasi akses node ke direktori Pod dan pengguna kontainer, gunakan masa berlaku pendek dan SAN minimal, serta tempatkan identitas bernilai tinggi di balik signer yang terisolasi atau dilindungi perangkat keras. Audit dan deteksi koneksi anomali mengurangi waktu respons.

Bagaimana jika feature gate dinonaktifkan?

Minta deployment controller mendeteksi sumber daya API, konfigurasi runtime, dan kapabilitas kubelet. Jeda workload atau beralih ke jalur lama yang diaudit saat prasyarat tidak terpenuhi; jangan pernah membuat file secara diam-diam yang tampak valid tetapi tidak akan dirotasi.