Gesaan dan skop
Ini ialah soalan infrastruktur identiti dan kebolehpercayaan bahagian belakang. ServiceAccount Kubernetes menggunakan JWT yang ditandatangani untuk mengakses pelayan API atau sistem lain yang mempercayai identiti tersebut. Dalam v1.36, penandatanganan token ServiceAccount luaran adalah stabil, membolehkan permintaan menandatangani meninggalkan pelayan API melalui soket domain Unix tempatan. Reka bentuk ini harus mengurangkan pendedahan kunci persendirian sambil mengekalkan semantik TokenRequest, pengesahan kunci awam, putaran, dan ketersediaan tinggi.
Perkara yang dinilai oleh penemu duga
- Sama ada anda mengasingkan penandatanganan, pengeluaran, pengesahan, dan kebenaran dan bukannya hanya menyebut "sambungkan KMS."
- Sama ada anda mereka bentuk tingkah laku sambungan UDS/gRPC, batas masa (deadlines), kebersamaan (concurrency), percubaan semula, dan pengendalian gagal-tutup (fail-closed).
- Sama ada anda mengendalikan kunci bertindih,
kidJWT, cache, dan penyegaran pengesah. - Sama ada anda memutar dan membuat rollback tanpa membatalkan token sah jangka pendek secara pramatang.
- Sama ada anda menentukan metrik audit, kependaman, ralat, dan penggunaan kunci.
Soalan penjelasan untuk ditanya
- Apakah TTL token, khalayak (audiences), QPS pengeluaran, dan bilangan replika pelayan API?
- Adakah penandatangan luaran menyediakan jaminan HSM, prob kesihatan, kunci berversi, dan ID kedegilan (idempotency)?
- Bagaimanakah pengesah memperoleh JWKS, dan apakah kelewatan penyegaran serta TTL cache?
- Apabila penandatangan tidak tersedia, bolehkah token baharu ditolak, atau adakah terdapat sandaran kunci lama yang terkawal?
- Adakah tugasan luar talian atau sistem di luar kluster bergantung pada JWT ini semasa putaran?
Jawapan 30 saat
"Saya akan membahagikan laluan kepada kebenaran TokenRequest, panggilan pelayan API ke penandatangan luaran, pengedaran kunci awam, dan kebenaran RBAC. Pelayan API memanggil penandatangan melalui soket Unix yang dilindungi dengan batas masa, ID permintaan, dan percubaan semula terhad; kunci persendirian kekal di dalam KMS atau HSM. Semasa putaran, terbitkan kunci awam baharu dan biarkan pengesah menyegar semula dengan pertindihan, kemudian keluarkan dengan kid baharu; persarakan kunci lama hanya selepas TTL token lama tamat tempoh. Jika penandatangan tidak tersedia, tolak pengeluaran baharu dan berikan amaran daripada mencipta token tanpa perlindungan secara senyap. Ukur kependaman penandatanganan, kadar penolakan, ralat soket, ID kunci, dan usia JWKS, serta simpan penandatangan dan kunci lama untuk rollback."
Perbincangan terperinci langkah demi langkah
Langkah 1: Tentukan kepercayaan dan aliran data
Kebenaran TokenRequest menentukan siapa yang boleh meminta token untuk ServiceAccount dan khalayak yang mana. Selepas mengesahkan permintaan, pelayan API menghantar muatan JWT ke penandatangan luaran; penandatangan mengembalikan tandatangan dan pelayan API mengembalikan token. Pelayan API masih memiliki semantik pengeluar (issuer), khalayak, tamat tempoh, dan RBAC. Sistem luaran hanya melakukan penandatanganan terkawal dan tidak boleh memberikan kebenaran tambahan.
Langkah 2: Reka bentuk antara muka penandatangan tempatan
Konfigurasi yang didokumenkan menghalakan --service-account-signing-endpoint ke soket domain Unix di mana protokol penandatanganan berversi boleh dijalankan. Hadkan kebenaran soket, direktori, identiti proses, dan dasar SELinux atau AppArmor kepada pelayan API sahaja. Sertakan versi kunci, algoritma, byte pencernaan atau penandatanganan, ID permintaan, dan batas masa dalam permintaan; kembalikan tandatangan, kid, dan ID korelasi audit. Jangan sekali-kali meletakkan kunci persendirian atau token lengkap dalam log biasa.
Langkah 3: Kendalikan batas masa, percubaan semula, dan idempotensi
Penandatanganan ialah laluan yang sensitif terhadap kependaman, jadi gunakan batas masa yang pendek dan kebersamaan terhad. Kegagalan rangkaian atau HSM sementara mungkin menerima percubaan semula terhad, tetapi percubaan semula tanpa had akan membesarkan barisan giliran pelayan API. ID permintaan mengaitkan audit penandatangan dan pelayan API; jika protokol menyokong caching idempoten, perakaunan pendua boleh dielakkan. Selepas tamat masa, kembalikan ralat eksplisit dan tolak pengeluaran baharu. Sama ada token sedia ada terus disahkan bergantung pada kunci awam dan dasar tamat tempoh.
Langkah 4: Reka bentuk putaran kunci dan pertindihan JWKS
Cipta kunci baharu dan benarkan penandatangan menggunakan kid baharunya, kemudian terbitkan kunci awam baharu dalam JWKS. Selepas pengesah menyegar semula, keluarkan token baharu dengan kunci tersebut. Simpan kunci awam lama untuk sekurang-kurangnya TTL token terpanjang ditambah tetingkap cache dan clock-skew (perbezaan masa jam). Jangan padamkannya semata-mata kerana pengeluar telah bertukar. Putaran mestilah boleh dijeda, boleh diaudit, dan boleh diterbalikkan.
Langkah 5: Kekalkan replika dan pemulihan bencana
Setiap replika pelayan API mesti mencapai penandatangan tempatan atau berketersediaan tinggi dengan versi kunci dan jam yang konsisten. Untuk penandatangan berpusat, nilaikan rangkaian rentas nod, domain kegagalan, dan radius letupan (blast radius). Untuk sidecar bagi setiap nod, pastikan ketersambungan HSM dan pengedaran kunci tidak menyimpang. Lakukan latihan untuk memulakan semula penandatangan, fail soket hilang, pendikit HSM, JWKS tidak tersedia, dan peningkatan berperingkat pelayan API.
Langkah 6: Sahkan, audit, dan buat rollback
Dayakan konfigurasi pada pelayan API kenari dan sahkan pengeluar TokenRequest, khalayak, kid, tamat tempoh, dan tingkah laku RBAC. Jalankan ujian integrasi merentasi kunci lama dan baharu, jenis pengesah, dan clock-skew. Jejaki p50/p95 penandatanganan, sebab kegagalan, kependaman soket, kiraan HSM, usia JWKS, dan kadar penolakan token. Lakukan rollback dengan memulihkan konfigurasi penandatangan dan kunci lama sambil mengekalkan kunci awam lama; jangan padamkannya sehingga token lama dan tetingkap audit telah berakhir.
Contoh jawapan berkualiti tinggi
"Saya akan menjadikan penandatangan luaran sebagai sempadan penandatanganan yang sempit. Pelayan API masih mengesahkan TokenRequest, pengeluar, khalayak, tamat tempoh, dan RBAC, memanggil penandatangan melalui soket Unix yang dilindungi, dan menyimpan kunci persendirian hanya dalam KMS atau HSM. Permintaan membawa versi, kid, ID, batas masa, dan percubaan semula terhad; kegagalan penandatangan menolak token baharu dan memberi amaran. Putaran menerbitkan JWKS baharu, menunggu penyegaran pengesah, menukar pengeluaran kepada kid baharu, dan mengekalkan kunci lama melalui tetingkap TTL terpanjang, cache, dan clock-skew. Setiap replika mesti mempunyai akses soket tempatan, versi kunci, dan masa yang konsisten. Ujian kenari menyemak kependaman, kadar penolakan, pengedaran ID kunci, usia JWKS, dan integrasi RBAC, manakala rollback mengekalkan penandatangan dan kunci awam lama."
Kesilapan lazim
- Membiarkan penandatangan luaran memutuskan RBAC atau khalayak dan meluaskan tanggungjawabnya.
- Menyalin kunci persendirian ke sidecar atau log, kehilangan faedah keselamatan.
- Memadamkan kunci awam lama serta-merta selepas putaran dan merosakkan token yang masih sah.
- Mencuba semula batas masa penandatangan tanpa had dan membebankan barisan giliran pelayan API.
- Hanya menguji penandatanganan yang berjaya dan bukannya cache JWKS, clock-skew, dan konsistensi replika.
- Menganggap pengeluaran kunci lama secara senyap semasa kegagalan penandatangan sebagai sandaran yang boleh dipercayai tanpa sempadan audit.
Soalan susulan dan jawapan
Bolehkah pelayan API terus menggunakan kunci persendirian lama tempatan jika penandatangan terhenti?
Hanya jika model ancaman eksplisit, audit, dan pelan rollback membenarkannya. Tetapan lalai harus menolak pengeluaran baharu supaya rahsia tidak kembali ke pelayan API. Token sedia ada boleh terus disahkan dengan kunci awam lama sehingga TTL-nya berakhir.
Bilakah selamat untuk memadam kunci awam lama?
Kira tetingkap keselamatan daripada TTL token terpanjang, TTL cache JWKS pengesah, clock-skew maksimum, dan pengekalan pengguna luar talian, kemudian sahkan bahawa penggunaan kid lama adalah sifar. Padamkan hanya selepas tetingkap tersebut berakhir dan simpan sandaran yang boleh dipulihkan terlebih dahulu.
Mengapa menggunakan soket Unix dan bukannya HTTP?
Soket tempatan menyempitkan permukaan pendengaran dan menggunakan kebenaran fail serta dasar hos untuk mengawal akses. Ia tidak menyelesaikan pengesahan protokol, pengasingan proses, atau ketersediaan dengan sendirinya; API berversi, audit, batas masa, dan latihan kegagalan masih diperlukan.