Permintaan dan ruang lingkup
Pertanyaan backend ini menguji siklus hidup sertifikat dan batasan komunikasi antar-layanan. Intinya bukan menyalin sertifikat baru ke setiap mesin; penerbitan, pembaruan kepercayaan, penggantian koneksi, dan rollback memerlukan tumpang tindih temporal.
Apa yang dinilai oleh pewawancara
- Apakah Anda membedakan migrasi sertifikat leaf, trust bundle, dan root CA.
- Apakah Anda menangani koneksi berumur panjang, cache, clock skew, pembaruan konkuren, dan kegagalan node parsial.
- Apakah Anda menggunakan identitas beban kerja berumur pendek daripada menaruh kunci privat dalam image atau variabel lingkungan.
- Apakah Anda dapat menentukan canary, pemeriksaan penerimaan, rollback, dan peringatan kedaluwarsa.
Pertanyaan klarifikasi yang perlu diajukan
Konfirmasikan penemuan layanan (service discovery), koneksi pendek versus panjang, penerbit (issuer), kepercayaan lintas-klaster atau lintas-domain, cara klien memuat kunci, batas waktu maksimum permintaan dan koneksi, serta apakah dua root atau sertifikat dapat hidup berdampingan. Perjelas apakah targetnya adalah sertifikat leaf, intermediate CA, atau seluruh domain kepercayaan.
Kerangka jawaban 30 detik
Saya akan membagi rotasi menjadi kepercayaan terlebih dahulu, sertifikat kedua, dan penggantian koneksi secara bertahap. Pertama, buat setiap pemverifikasi menerima root lama dan baru, kemudian terbitkan sertifikat leaf berumur pendek pada rantai baru. Klien dan proxy memuat pasangan kunci baru secara atomik dan mempertahankan materi lama hingga koneksi terkuras. Selama canary, saya akan memantau kegagalan handshake, masa pakai sertifikat, versi bundle, dan percobaan ulang (retry); jika ada anomali, saya akan menghentikan penerbitan dan memulihkan jalur lama, dan tidak akan pernah menonaktifkan verifikasi sertifikat sebagai langkah rollback.
Solusi langkah demi langkah
1. Tetapkan identitas dan domain kepercayaan
Beri setiap beban kerja SPIFFE ID yang stabil atau identitas yang setara, memisahkan produksi, staging, dan domain kepercayaan yang berbeda. Pemverifikasi memegang trust bundle, sementara penerbit menandatangani hanya setelah atestasi beban kerja yang sah. Beban kerja menghasilkan kunci privatnya sendiri dan membatasi akses; control plane tidak boleh mendistribusikan kunci privat berumur panjang melalui konfigurasi aplikasi.
2. Publikasikan trust bundle yang kompatibel terlebih dahulu
Untuk migrasi root atau intermediate CA, publikasikan trust bundle dual-root dan konfirmasikan bahwa pemverifikasi telah memuat versi barunya. Jangan langsung menghapus root lama karena sertifikat lama dan koneksi berumur panjang masih ada. Lacak versi bundle, keberhasilan pemuatan, dan instans yang usang sebelum memulai penerbitan sertifikat baru.
3. Terbitkan dan muat sertifikat baru
Beban kerja memperoleh identitas X.509 berumur pendek melalui Workload API, sidecar, atau antarmuka dinamis yang setara. Perbarui dalam jendela waktu awal dan ganti kunci serta sertifikat secara atomik: pembaca melihat pasangan lama atau pasangan baru, tidak pernah campuran keduanya. Jika gagal, pertahankan materi valid terakhir dan coba lagi; jangan memperpanjang sertifikat yang kedaluwarsa selamanya.
4. Tangani batasan koneksi dan permintaan
Sertifikat baru biasanya memengaruhi sesi TLS baru, sementara koneksi berumur panjang dapat mempertahankan sertifikat lama. Tetapkan usia koneksi maksimum untuk HTTP/2, gRPC, atau pool basis data dan kuras koneksi lama secara halus (gracefully drain) setelah handshake baru berhasil. Percobaan ulang harus mematuhi idempoten, batas waktu (timeout), dan backoff agar rotasi tidak membesar menjadi badai percobaan ulang (retry storm).
5. Rancang canary, rollback, dan penghapusan root
Validasi satu pool beban kerja dan satu jalur lalu lintas terlebih dahulu, lalu perluas berdasarkan wilayah atau layanan. Rollback menghentikan penerbitan baru dan memulihkan bundle serta kebijakan koneksi lama; hapus root lama hanya setelah semua sertifikat dan koneksi lama terkuras. Jika kunci privat root baru disusupi, pencabutan dan isolasi darurat harus independen dari alur kerja rotasi normal.
6. Observasi dan latih skenario kegagalan
Pantau persentil masa pakai sertifikat, kegagalan penerbitan, penundaan pembaruan SVID atau bundle, kesalahan handshake TLS, 4xx/5xx yang dikelompokkan berdasarkan identitas dan versi, serta durasi pengurasan. Latih peringatan kedaluwarsa, clock skew, ketidaktersediaan control plane, dan wilayah yang tidak dapat memperbarui dengan identitas pengujian. Log mencatat identitas, versi, dan hasil, tidak pernah mencatat kunci privat.
Contoh jawaban berkualitas tinggi
Pertama-tama saya akan mengidentifikasi apakah ini merupakan rotasi leaf, CA, atau domain kepercayaan, lalu memberi setiap beban kerja identitas yang stabil dan SVID X.509 berumur pendek. Untuk migrasi CA, saya akan memublikasikan trust bundle dual-root dan mengonfirmasi bahwa pemverifikasi memuatnya sebelum menerbitkan sertifikat leaf baru secara dinamis melalui Workload API atau proxy. Ganti kunci dan sertifikat secara atomik serta pertahankan materi lama yang valid; koneksi baru menggunakan sertifikat baru, sementara koneksi HTTP/2 dan gRPC dikuras pada batas usia maksimum tertentu. Rilis secara bertahap berdasarkan pool beban kerja dan wilayah, memantau kesalahan handshake, versi bundle, sisa masa pakai, dan tingkat percobaan ulang. Jika terjadi kegagalan, hentikan penerbitan dan pulihkan bundle serta kebijakan koneksi lama; jangan pernah menonaktifkan verifikasi. Hapus root lama hanya setelah sertifikat dan koneksi lama terkuras. Latih skenario kedaluwarsa, clock skew, dan kegagalan control plane dengan identitas uji, serta jauhkan kunci privat dari image, variabel lingkungan, dan log.
Kesalahan umum
- Menghapus root lama sebelum memublikasikan yang baru, merusak node yang masih menggunakan sertifikat lama.
- Mengganti file tanpa menangani koneksi berumur panjang, pool, dan permintaan yang sedang berjalan (in-flight).
- Memasukkan kunci privat ke dalam image, variabel lingkungan, atau penyimpanan konfigurasi biasa.
- Mengganti kunci dan sertifikat secara terpisah sehingga menghasilkan pasangan yang tidak cocok.
- Menonaktifkan verifikasi TLS atau memperpanjang sertifikat yang kedaluwarsa selamanya saat terjadi kegagalan.
- Hanya memiliki peringatan kedaluwarsa di saat-saat terakhir tanpa telemetri versi bundle, handshake, atau keterlambatan pembaruan.
Pertanyaan lanjutan dan tanggapan
Mengapa harus menerima rantai lama dan baru di dalam bundle terlebih dahulu?
Pemverifikasi mempelajari root baru sementara sertifikat lama tetap berfungsi, sehingga tidak pernah ada celah antara penerbitan dan validasi. Hapus root lama hanya setelah sertifikat dan koneksi yang menggunakannya terkuras habis.
Apa yang terjadi pada koneksi berumur panjang setelah pembaruan?
Batasi usia maksimumnya, kuras secara halus, dan tutup setelah koneksi baru menyelesaikan handshake-nya. Permintaan yang dapat dicoba ulang tetap mengikuti aturan idempoten dan backoff; jangan menyambungkan kembali semua klien sekaligus.
Apakah ketidaktersediaan control plane sementara langsung menghentikan layanan?
Tidak. Simpan identitas dan bundle dalam cache selama masih valid, perbarui lebih awal, dan beri peringatan tentang sisa masa pakai. Cache harus memiliki batas keamanan dan kepatuhan yang eksplisit daripada menjadi jalan pintas tanpa batas.
Bagaimana Anda membuktikan tidak ada lagi layanan yang bergantung pada root lama?
Catat handshake dan pemuatan berdasarkan identitas, rantai sertifikat, dan versi bundle, lalu konfirmasikan nol penggunaan rantai lama selama jendela observasi. Isolasi atau rollback node yang tidak dapat melaporkan alih-alih berasumsi bahwa mereka telah diperbarui.