Gesaan dan skop
Soalan backend ini menguji kitaran hayat sijil dan sempadan komunikasi antara perkhidmatan. Tujuannya bukan sekadar menyalin sijil baharu ke setiap mesin; pengeluaran, kemas kini kepercayaan, penggantian sambungan, dan rollback memerlukan pertindihan masa.
Perkara yang dinilai oleh penemu duga
- Sama ada anda membezakan migrasi sijil leaf, trust bundle, dan root CA.
- Sama ada anda mengendalikan sambungan jangka panjang, cache, penyelewengan jam (clock skew), kemas kini serentak, dan kegagalan nod separa.
- Sama ada anda menggunakan identiti beban kerja jangka pendek dan bukannya meletakkan kunci peribadi dalam imej atau pemboleh ubah persekitaran.
- Sama ada anda boleh mentakrifkan canary, semakan penerimaan, rollback, dan amaran tamat tempoh.
Soalan penjelasan untuk ditanya
Sahkan penemuan perkhidmatan (service discovery), sambungan pendek berbanding panjang, pengeluar (issuer), kepercayaan rentas kluster atau rentas domain, cara klien memuatkan kunci, jangka hayat maksimum permintaan dan sambungan, serta sama ada dua root atau sijil boleh wujud bersama. Jelaskan sama ada sasarannya ialah leaf, intermediate CA, atau keseluruhan domain kepercayaan.
Rangka jawapan 30 saat
Saya akan membahagikan putaran kepada kepercayaan terlebih dahulu, sijil kedua, dan penggantian sambungan secara beransur-ansur. Mula-mula pastikan setiap pengesah menerima root lama dan baharu, kemudian keluarkan sijil leaf jangka pendek pada rantai baharu. Klien dan proksi memuatkan pasangan kunci baharu secara atomik dan mengekalkan bahan lama sehingga sambungan disalirkan. Semasa canary, saya akan memerhatikan kegagalan jabat tangan (handshake), jangka hayat sijil, versi bundle, dan percubaan semula; sekiranya berlaku keabnormalan, saya akan menghentikan pengeluaran dan memulihkan laluan lama, tidak sekali-kali menyahdayakan pengesahan sijil sebagai rollback.
Penyelesaian langkah demi langkah
1. Wujudkan domain identiti dan kepercayaan
Berikan setiap beban kerja SPIFFE ID yang stabil atau identiti yang setara, memisahkan pengeluaran, pementasan, dan domain kepercayaan yang berbeza. Pengesah memegang trust bundle, manakala pengeluar hanya menandatangani selepas pengesahan (attestation) beban kerja yang dibenarkan. Beban kerja menjana kunci peribadinya sendiri dan mengehadkan akses; satah kawalan (control plane) tidak seharusnya mengedarkan kunci peribadi jangka panjang melalui konfigurasi aplikasi.
2. Terbitkan trust bundle yang serasi terlebih dahulu
Untuk migrasi root atau intermediate CA, terbitkan trust bundle dwi-root dan sahkan bahawa pengesah telah memuatkan versi baharunya. Jangan padamkan root lama serta-merta kerana sijil lama dan sambungan jangka panjang masih wujud. Jejak versi bundle, kejayaan pemuatan, dan tika lapuk sebelum memulakan pengeluaran sijil baharu.
3. Keluarkan dan muatkan sijil baharu
Beban kerja memperoleh identiti X.509 jangka pendek melalui Workload API, sidecar, atau antara muka dinamik yang setara. Perbaharui dalam tetingkap awal dan gantikan kunci serta sijil secara atomik: pembaca melihat sama ada pasangan lama atau pasangan baharu, tidak sekali-kali campurannya. Sekiranya berlaku kegagalan, kekalkan bahan sah yang terakhir dan cuba semula; jangan lanjutkan sijil yang telah tamat tempoh selama-lamanya.
4. Kendalikan sempadan sambungan dan permintaan
Sijil baharu biasanya mempengaruhi sesi TLS baharu, manakala sambungan jangka panjang mungkin mengekalkan sijil lama. Tetapkan usia sambungan maksimum untuk HTTP/2, gRPC, atau kolam pangkalan data dan salirkan sambungan lama secara tertib (gracefully drain) selepas jabat tangan baharu berjaya. Percubaan semula mesti mematuhi keidempotensian, had masa tamat (timeout), dan backoff supaya putaran tidak membesar menjadi ribut percubaan semula (retry storm).
5. Reka bentuk canary, rollback, dan penyingkiran root
Sahkan satu kolam beban kerja dan satu laluan trafik terlebih dahulu, kemudian kembangkan mengikut rantau atau perkhidmatan. Rollback menghentikan pengeluaran baharu dan memulihkan bundle serta dasar sambungan lama; alih keluar root lama hanya selepas semua sijil dan sambungan lama disalirkan. Jika kunci peribadi root baharu terjejas, pembatalan dan pengasingan kecemasan mesti bebas daripada aliran kerja putaran biasa.
6. Perhatikan dan buat raptai kegagalan
Pantau persentil jangka hayat sijil, kegagalan pengeluaran, kelewatan kemas kini SVID atau bundle, ralat jabat tangan TLS, 4xx/5xx yang dikumpulkan mengikut identiti dan versi, serta tempoh penyaliran. Buat raptai amaran tamat tempoh, penyelewengan jam, ketiadaan satah kawalan, dan rantau yang tidak boleh dikemas kini menggunakan identiti ujian. Log merekodkan identiti, versi, dan hasil, tidak sekali-kali kunci peribadi.
Contoh jawapan berkualiti tinggi
Saya akan mengenal pasti terlebih dahulu sama ada ini adalah putaran leaf, CA, atau domain kepercayaan, kemudian memberi setiap beban kerja identiti yang stabil dan X.509 SVID jangka pendek. Untuk migrasi CA, saya akan menerbitkan trust bundle dwi-root dan mengesahkan bahawa pengesah memuatkannya sebelum mengeluarkan sijil leaf baharu secara dinamik melalui Workload API atau proksi. Gantikan kunci dan sijil secara atomik dan kekalkan bahan lama yang sah; sambungan baharu menggunakan sijil baharu, manakala sambungan HTTP/2 dan gRPC disalirkan pada usia maksimum yang terhad. Lancarkan mengikut kolam beban kerja dan rantau, memerhatikan ralat jabat tangan, versi bundle, baki jangka hayat, dan kadar percubaan semula. Sekiranya berlaku kegagalan, hentikan pengeluaran dan pulihkan bundle serta dasar sambungan lama; jangan sekali-kali menyahdayakan pengesahan. Alih keluar root lama hanya selepas sijil dan sambungan lama disalirkan. Buat raptai tamat tempoh, penyelewengan jam, dan kegagalan satah kawalan dengan identiti ujian, dan jauhkan kunci peribadi daripada imej, pemboleh ubah persekitaran, dan log.
Kesilapan biasa
- Memadamkan root lama sebelum menerbitkan yang baharu, merosakkan nod yang masih menggunakan sijil lama.
- Menggantikan fail tanpa mengendalikan sambungan jangka panjang, kolam sambungan, dan permintaan dalam penerbangan (in-flight).
- Menyematkan kunci peribadi ke dalam imej, pemboleh ubah persekitaran, atau stor konfigurasi biasa.
- Menukar kunci dan sijil secara berasingan lalu menghasilkan pasangan yang tidak sepadan.
- Menyahdayakan pengesahan TLS atau melanjutkan sijil yang telah tamat tempoh selama-lamanya semasa kegagalan.
- Hanya mempunyai amaran tamat tempoh pada saat-saat akhir tanpa telemetri versi bundle, jabat tangan, atau kelewatan kemas kini.
Soalan susulan dan jawapan
Mengapa perlu menerima kedua-dua rantai lama dan baharu dalam bundle terlebih dahulu?
Pengesah mempelajari root baharu manakala sijil lama terus berfungsi, jadi pengeluaran dan pengesahan tidak pernah mengalami jurang. Alih keluar root lama hanya selepas sijil dan sambungan yang menggunakannya disalirkan sepenuhnya.
Apakah yang berlaku kepada sambungan jangka panjang selepas pembaharuan?
Hadkan usia maksimumnya, salirkan secara tertib, dan tutupnya selepas sambungan baharu menyelesaikan jabat tangannya. Permintaan yang boleh dicuba semula masih mematuhi peraturan keidempotensian dan backoff; jangan sambung semula semua klien secara serentak.
Adakah ketiadaan satah kawalan sementara akan menghentikan perkhidmatan serta-merta?
Tidak. Simpan identiti dan bundle dalam cache selagi ia masih sah, perbaharui lebih awal, dan berikan amaran tentang baki jangka hayat. Cache mesti mempunyai had keselamatan dan pematuhan yang jelas dan bukannya menjadi pintasan tanpa had.
Bagaimanakah anda membuktikan tiada perkhidmatan yang masih bergantung pada root lama?
Rekod jabat tangan dan pemuatan mengikut identiti, rantai sijil, dan versi bundle, kemudian sahkan sifar penggunaan rantai lama semasa tetingkap pemerhatian. Asingkan atau lakukan rollback pada nod yang tidak dapat melaporkan dan bukannya menganggap bahawa ia telah dikemas kini.