Petunjuk dan cakupan
Ini adalah pertanyaan infrastruktur identitas dan keandalan backend. ServiceAccount Kubernetes menggunakan JWT yang ditandatangani untuk mengakses server API atau sistem lain yang memercayai identitas tersebut. Di v1.36, penandatanganan token ServiceAccount eksternal sudah stabil, memungkinkan permintaan penandatanganan keluar dari server API melalui soket domain Unix lokal. Rancangan harus mengurangi eksposur kunci privat sambil tetap mempertahankan semantik TokenRequest, verifikasi kunci publik, rotasi, dan ketersediaan tinggi (high availability).
Apa yang dievaluasi pewawancara
- Apakah Anda memisahkan penandatanganan, penerbitan, verifikasi, dan otorisasi alih-alih hanya mengatakan “hubungkan KMS”.
- Apakah Anda merancang perilaku koneksi UDS/gRPC, batas waktu (deadline), konkurensi, percobaan ulang (retry), dan penanganan fail-closed.
- Apakah Anda menangani kunci yang tumpang tindih (overlapping keys),
kidJWT, cache, dan pembaruan verifikator. - Apakah Anda melakukan rotasi dan rollback tanpa mencabut token berumur pendek yang valid sebelum waktunya.
- Apakah Anda mendefinisikan metrik audit, latensi, kesalahan, dan penggunaan kunci.
Pertanyaan klarifikasi yang perlu diajukan
- Berapa TTL token, audiens, QPS penerbitan, dan jumlah replika server API?
- Apakah penandatangan eksternal menyediakan jaminan HSM, pemeriksaan kesehatan (health probe), kunci berversi, dan ID idempoten?
- Bagaimana verifikator memperoleh JWKS, dan berapa penundaan pembaruan serta TTL cache?
- Ketika penandatangan tidak tersedia, apakah token baru boleh ditolak, atau apakah ada fallback kunci lama yang terkontrol?
- Apakah tugas offline atau sistem di luar kluster bergantung pada JWT ini selama rotasi?
Jawaban 30 detik
“Saya akan membagi alur menjadi otorisasi TokenRequest, panggilan server API ke penandatangan eksternal, distribusi kunci publik, dan otorisasi RBAC. Server API memanggil penandatangan melalui soket Unix yang dilindungi dengan batas waktu, ID permintaan, dan percobaan ulang yang dibatasi; kunci privat tetap berada di dalam KMS atau HSM. Selama rotasi, publikasikan kunci publik baru dan biarkan verifikator memperbarui dengan masa tumpang tindih, lalu terbitkan dengan kid baru; hentikan kunci lama hanya setelah TTL token lama kedaluwarsa. Jika penandatangan tidak tersedia, tolak penerbitan baru dan berikan peringatan daripada secara diam-diam membuat token yang tidak terlindungi. Ukur latensi penandatanganan, tingkat penolakan, kesalahan soket, ID kunci, dan usia JWKS, serta pertahankan penandatangan dan kunci lama untuk rollback.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan kepercayaan dan aliran data
Otorisasi TokenRequest menentukan siapa yang boleh meminta token untuk ServiceAccount dan audiens mana. Setelah memvalidasi permintaan, server API mengirimkan payload JWT ke penandatangan eksternal; penandatangan mengembalikan tanda tangan dan server API mengembalikan token. Server API tetap memiliki semantik penerbit (issuer), audiens, masa kedaluwarsa, dan RBAC. Sistem eksternal hanya melakukan penandatanganan terkontrol dan tidak boleh memberikan izin tambahan.
Langkah 2: Rancang antarmuka penandatangan lokal
Konfigurasi yang terdokumentasi mengarahkan --service-account-signing-endpoint ke soket domain Unix tempat protokol penandatanganan berversi dapat berjalan. Batasi izin soket, direktori, identitas proses, dan kebijakan SELinux atau AppArmor hanya untuk server API. Sertakan versi kunci, algoritma, digest atau byte penandatanganan, ID permintaan, dan batas waktu dalam permintaan; kembalikan tanda tangan, kid, dan ID korelasi audit. Jangan pernah menaruh kunci privat atau token lengkap di log biasa.
Langkah 3: Tangani batas waktu, percobaan ulang, dan idempotensi
Penandatanganan adalah jalur yang sensitif terhadap latensi, jadi gunakan batas waktu yang singkat dan konkurensi yang dibatasi. Kegagalan jaringan atau HSM sementara dapat menerima percobaan ulang yang terbatas, tetapi percobaan ulang tanpa batas akan memperbesar antrean server API. ID permintaan mengorelasikan audit penandatangan dan server API; jika protokol mendukung caching idempoten, akuntansi ganda dapat dihindari. Setelah waktu habis, kembalikan kesalahan eksplisit dan tolak penerbitan baru. Apakah token yang ada terus terverifikasi bergantung pada kunci publik dan kebijakan kedaluwarsa.
Langkah 4: Rancang rotasi kunci dan tumpang tindih JWKS
Buat kunci baru dan izinkan penandatangan menggunakan kid barunya, lalu publikasikan kunci publik baru di JWKS. Setelah verifikator memperbarui, terbitkan token baru dengan kunci tersebut. Simpan kunci publik lama setidaknya selama TTL token terpanjang ditambah jendela cache dan clock-skew (perbedaan waktu). Jangan menghapusnya hanya karena penerbit telah beralih. Rotasi harus dapat dijeda, diaudit, dan dibalikkan (reversible).
Langkah 5: Pertahankan replika dan pemulihan bencana
Setiap replika server API harus mencapai penandatangan lokal atau yang berketersediaan tinggi dengan versi kunci dan jam yang konsisten. Untuk penandatangan terpusat, evaluasi jaringan lintas-node, domain kegagalan, dan radius dampak (blast radius). Untuk sidecar per-node, pastikan konektivitas HSM dan distribusi kunci tidak berbeda. Uji mulai ulang penandatangan, berkas soket yang hilang, throttling HSM, JWKS yang tidak tersedia, dan peningkatan bertahap (rolling upgrade) server API.
Langkah 6: Verifikasi, audit, dan rollback
Aktifkan konfigurasi pada server API canary dan verifikasi penerbit TokenRequest, audiens, kid, kedaluwarsa, dan perilaku RBAC. Jalankan pengujian integrasi di seluruh kunci lama dan baru, jenis verifikator, dan clock-skew. Lacak p50/p95 penandatanganan, alasan kegagalan, latensi soket, hitungan HSM, usia JWKS, dan tingkat penolakan token. Lakukan rollback dengan memulihkan konfigurasi penandatangan dan kunci lama sambil mempertahankan kunci publik lama; jangan menghapusnya sampai token lama dan jendela audit berakhir.
Contoh jawaban berkualitas tinggi
“Saya akan menjadikan penandatangan eksternal sebagai batas penandatanganan yang sempit. Server API tetap memvalidasi TokenRequest, penerbit, audiens, kedaluwarsa, dan RBAC, memanggil penandatangan melalui soket Unix yang dilindungi, dan menyimpan kunci privat hanya di KMS atau HSM. Permintaan membawa versi, kid, ID, batas waktu, dan percobaan ulang terbatas; kegagalan penandatangan menolak token baru dan memberi peringatan. Rotasi memublikasikan JWKS baru, menunggu pembaruan verifikator, mengalihkan penerbitan ke kid baru, dan mempertahankan kunci lama melalui jendela TTL terpanjang, cache, dan clock-skew. Setiap replika harus memiliki akses soket lokal, versi kunci, dan waktu yang konsisten. Canary memeriksa latensi, tingkat penolakan, distribusi ID kunci, usia JWKS, dan integrasi RBAC, sementara rollback mempertahankan penandatangan dan kunci publik lama.”
Kesalahan umum
- Membiarkan penandatangan eksternal menentukan RBAC atau audiens dan memperluas tanggung jawabnya.
- Menyalin kunci privat ke sidecar atau log, kehilangan manfaat keamanan.
- Menghapus kunci publik lama segera setelah rotasi dan merusak token yang masih valid.
- Mencoba ulang batas waktu penandatangan tanpa batas dan membebani antrean server API secara berlebihan.
- Hanya menguji penandatanganan yang berhasil alih-alih cache JWKS, clock-skew, dan konsistensi replika.
- Memperlakukan penerbitan kunci lama secara diam-diam selama kegagalan penandatangan sebagai fallback yang andal tanpa batasan audit.
Pertanyaan lanjutan dan jawaban
Bisakah server API tetap menggunakan kunci privat lama lokal jika penandatangan tidak aktif?
Hanya jika model ancaman eksplisit, audit, dan rencana rollback mengizinkannya. Pengaturan default harus menolak penerbitan baru agar rahasia tidak kembali ke server API. Token yang ada dapat terus memverifikasi dengan kunci publik lama hingga TTL-nya berakhir.
Kapan aman untuk menghapus kunci publik lama?
Hitung jendela keamanan dari TTL token terpanjang, TTL cache JWKS verifikator, clock-skew maksimum, dan retensi konsumen offline, lalu verifikasi bahwa penggunaan kid lama adalah nol. Hapus hanya setelah jendela tersebut berlalu dan pertahankan cadangan yang dapat dipulihkan terlebih dahulu.
Mengapa menggunakan soket Unix alih-alih HTTP?
Soket lokal mempersempit area mendengarkan (listening surface) dan menggunakan izin berkas serta kebijakan host untuk mengontrol akses. Ini tidak menyelesaikan autentikasi protokol, isolasi proses, atau ketersediaan dengan sendirinya; API berversi, audit, batas waktu, dan latihan kegagalan tetap diperlukan.