Wawancara Backend: Mengapa Memverifikasi Kredensial Pull untuk Image Kubernetes yang Di-cache?

Prompt dan kasus penggunaan

Ketika image privat sudah ada di sebuah node, apakah Kubernetes harus tetap memverifikasi imagePullSecrets? Bagaimana Anda memilih kebijakan dan menerapkannya secara aman? Prompt backend ini menguji perilaku runtime kontainer, siklus hidup kredensial, dan isolasi tenant. Asumsikan IfNotPresent, node yang berpotensi digunakan bersama, registry yang mendukung kredensial berumur pendek, dan persyaratan untuk menghindari perubahan keamanan menjadi pemadaman skala luas (fleet-wide outage).

Hal yang dinilai oleh pewawancara

• Apakah Anda memisahkan antara "byte ada di node ini" dari "workload ini berwenang untuk menggunakannya."
• Apakah Anda menjelaskan cara kubelet mencatat pull yang berhasil beserta kredensialnya, dan mengapa preloaded image memerlukan perlakuan terpisah.
• Apakah Anda membandingkan NeverVerify, NeverVerifyPreloadedImages, allowlist, dan AlwaysVerify berdasarkan risiko dan biaya.
• Apakah Anda menangani rotasi, reboot node, catatan cache yang hilang, kegagalan registry, dan rollback.

Pertanyaan klarifikasi sebelum menjawab

Mulailah dengan model ancaman: apakah node bersifat multi-tenant, apakah image berisi kode sensitif, dan dapatkah penyerang membuat Pod? Tanyakan apakah image di-pull oleh kubelet atau di-preload sebelum node dimulai, dan apakah kredensial berasal dari Secret Pod, identitas node, atau token service-account. Perjelas apakah rotasi harus segera mencabut akses lama, apakah verifikasi offline dapat diterima, dan berapa banyak traffic repull yang dapat diserap oleh registry. Terakhir, tentukan apakah tujuannya adalah kompatibilitas mundur, isolasi yang lebih kuat, atau kebijakan yang lebih ketat untuk namespace sensitif.

Kerangka jawaban 30 detik

"Saya akan memisahkan cache hit image dari otorisasi. Node multi-tenant atau image sensitif tidak boleh melewati imagePullSecrets hanya karena byte-nya sudah ada. Saya akan mengaktifkan pencatatan pull, memulai dengan pengecualian preloaded-image, lalu beralih menuju AlwaysVerify berdasarkan node pool dan namespace. Batasan pengaman mencakup keberhasilan startup, tingkat repull, latensi registry, efektivitas rotasi, dan penolakan lintas-tenant. Peluncuran ini memerlukan migrasi catatan cache, perilaku saat registry padam, dan rollback feature-gate."

Jawaban mendalam langkah demi langkah

1. Pisahkan keputusan: Cache menjawab apakah byte data ada; verifikasi kredensial menjawab apakah permintaan ini boleh menggunakannya. IfNotPresent bukanlah kebijakan otorisasi.
2. Catat relasi yang berhasil: Kubelet mencatat kredensial yang berhasil melakukan pull image. Kredensial yang sama dapat diperiksa secara lokal; kredensial yang tidak dikenal atau telah dirotasi memerlukan pull dari registry dan otorisasi.
3. Tangani preloaded image: Image yang dimuat di luar kubelet tidak memiliki catatan pull. NeverVerifyPreloadedImages mempertahankan kompatibilitas, NeverVerifyAllowListedImages mempersempit pengecualian, dan AlwaysVerify memeriksa semua image.
4. Rancang rotasi: Catatan kredensial yang berhasil sebelumnya tidak membuktikan bahwa kredensial baru berfungsi. Rotasi harus memicu repull atau pembatalan eksplisit, dengan pemantauan terhadap registry throttling dan latensi startup.
5. Kelola risiko peningkatan (upgrade): Pada pengaktifan pertama kali, image yang ada dapat diperlakukan sebagai preloaded. Hapus entri cache yang tidak boleh dipercaya lagi dan perhitungkan restart kubelet serta migrasi file cache.
6. Tahapkan dan lakukan rollback: Aktifkan berdasarkan node pool, label workload, atau namespace berisiko rendah; pantau penolakan dan beban registry. Pertahankan NeverVerify atau feature gate sebagai jalur rollback cepat.

Contoh jawaban berkualitas tinggi

Saya akan memverifikasi, tetapi kebijakannya bergantung pada model ancaman. Cache hit hanya membuktikan bahwa node memiliki byte image; itu tidak membuktikan bahwa Pod saat ini boleh menggunakan image privat tersebut. Pada node multi-tenant, melewati verifikasi memungkinkan workload dengan kredensial berbeda menggunakan kembali image yang di-cache. Desain Kubernetes memungkinkan kubelet mencatat hubungan antara image dan kredensial yang berhasil melakukan pull: kredensial yang sama dapat diperiksa secara lokal, sedangkan kredensial yang tidak dikenal atau telah dirotasi memerlukan akses registry. Preloaded image tidak memiliki catatan tersebut, jadi saya akan memulai dengan NeverVerifyPreloadedImages demi kompatibilitas dan memindahkan node pool sensitif menuju AlwaysVerify; jika pengecualian diperlukan, gunakan allowlist preloaded-image yang eksplisit daripada menonaktifkan kontrol secara global. Sebelum mengaktifkannya, bersihkan cache yang tidak boleh dipercaya lagi dan lakukan latihan restart kubelet, migrasi catatan, registry throttling, dan rotasi kredensial. Selama canary, bandingkan keberhasilan startup Pod, tingkat repull, latensi P95 registry, penolakan otorisasi, dan upaya penggunaan kembali lintas-tenant. Jika pemadaman registry menyebabkan kegagalan cold-start yang luas, lakukan rollback pada gate atau kebijakan sambil tetap mempertahankan peringatan dan catatan audit. Ini menyatukan batasan keamanan, kompatibilitas, dan risiko kapasitas ke dalam satu keputusan rilis.

Kesalahan umum

• Menganggap digest image sebagai bukti bahwa setiap namespace berwenang untuk menggunakan image tersebut.
• Mengatakan "aktifkan AlwaysVerify" tanpa membahas preloaded image, reboot node, atau kegagalan registry.
• Menganggap rotasi kredensial hanya sebagai pembaruan Secret sambil mengabaikan catatan keberhasilan lama dan perilaku repull.
• Mengubah kebijakan di seluruh fleet tanpa canary per node-pool, kapasitas registry, dan sakelar rollback.
• Menyebut NeverVerifyPreloadedImages sebagai jaminan keamanan tanpa memverifikasi asal-usul preload dan allowlist.

Pertanyaan lanjutan dan jawaban

Mengapa kredensial yang sama dapat diperiksa tanpa permintaan registry lainnya?

Pull yang berhasil membuktikan bahwa registry menerima kredensial tersebut untuk image terkait, sehingga kubelet dapat memvalidasi hubungan yang diketahui secara lokal. Kredensial yang diubah, catatan yang hilang, atau kebijakan yang ketat memerlukan pull baru atau pemeriksaan registry.

Bagaimana jika catatan cache hilang setelah node di-reboot?

Pertahankan catatan di direktori kubelet dan migrasikan berdasarkan versi. Jika catatan tidak dapat dibaca, ambil jalur yang lebih ketat dan lakukan repull daripada secara diam-diam membuat image yang di-cache tersedia untuk siapa saja.

Haruskah image yang di-cache diizinkan ketika registry tidak tersedia untuk sementara?

Lingkungan berisiko rendah mungkin memiliki degradasi yang didefinisikan secara sempit, dapat diamati, dan berbatas waktu. Workload sensitif tidak boleh melewati otorisasi. Catat permintaan mana yang diizinkan saat offline sehingga insiden tidak menjadi izin berlebih permanen.

Bagaimana Anda membuktikan bahwa rotasi benar-benar berfungsi?

Jalankan image privat yang sama dengan Secret lama, Secret baru, tanpa Secret, dan identitas dari namespace yang berbeda. Periksa event kubelet, akses registry, catatan cache, dan hasil Pod. Verifikasi bahwa kredensial lama gagal, kredensial baru berhasil, dan throttling memicu perilaku rollback yang direncanakan.