Wawancara system design: Bagaimana cara memigrasikan Kubernetes ke KMS v2 dan membuktikan bahwa Secret terenkripsi?

Petunjuk dan cakupan

Tim platform harus melindungi Secret di etcd. Kluster memiliki beberapa kube-apiserver, plugin KMS eksternal, dan banyak objek historis, namun rilis tidak boleh berhenti selama migrasi. Rancang konfigurasi, rotasi, penulisan ulang (rewrite), verifikasi, pemantauan, dan rollback.

Apa yang diuji oleh pewawancara

• Pemahaman tentang batasan envelope encryption pada KMS v2 dan hubungan DEK/KEK.
• Membedakan penulisan baru yang terenkripsi dari objek historis yang ditulis ulang.
• Menangani beberapa apiserver, pemadaman KMS, rotasi, dan pembaruan bersamaan (concurrent updates).
• Membuktikan hasil dengan bukti etcd dan pembacaan API, bukan hanya sekadar config diff.

Pertanyaan klarifikasi

1. Versi Kubernetes dan plugin apa, serta topologi ketersediaan tinggi (high-availability) mana yang diterapkan?
2. Sumber daya apa saja yang dilindungi, termasuk custom resources dan log audit?
3. Jaminan ketersediaan, latensi, rotasi, dan pemulihan bencana apa yang disediakan oleh KMS eksternal?
4. Jendela control-plane, batas waktu rollback, dan format bukti kepatuhan apa yang diperlukan?

Jawaban 30 detik

Validasi plugin KMS v2 dan izin di kluster non-produksi. Jadikan KMS sebagai penyedia (provider) pertama, pertahankan provider lama sebagai fallback baca, dan lakukan rolling update pada setiap kube-apiserver satu per satu. Penulisan baru akan terenkripsi, tetapi objek historis memerlukan pembaruan no-op atau migrasi storage-version. Verifikasi pembacaan API, prefiks etcd, metrik KMS, latihan kegagalan, dan catatan audit. Hapus provider lama hanya setelah setiap objek ditulis ulang dan jendela rollback telah berakhir.

Desain langkah demi langkah

1. Tentukan model enkripsi

Kubernetes menggunakan enkripsi amplop (envelope encryption): kunci enkripsi data (DEK) melindungi sumber daya, sedangkan kunci enkripsi kunci (KEK) dilindungi oleh KMS eksternal. KMS v2 menurunkan beban permintaan dengan caching sisi server dan desain DEK per-apiserver, namun tidak menulis ulang setiap nilai lama di etcd secara otomatis.

2. Validasi plugin dan izin terlebih dahulu

Dalam kluster yang terisolasi, uji soket, identitas, batas waktu (timeout), restart, dan perilaku saat KMS tidak tersedia. Konfirmasikan bahwa kube-apiserver dapat mendekripsi objek yang ditulis oleh provider lama dan menulis Secret baru melalui provider baru. Catat latensi, kesalahan, cache hits, dan volume panggilan KMS.

providers:
  - kms:
      apiVersion: v2
      name: external-kms
      endpoint: unix:///var/run/kms/plugin.sock
  - aescbc:
      keys:
        - name: old-key
          secret: <base64-secret>

3. Lakukan roll pada control plane berkeandalan tinggi (HA)

Tempatkan KMS di urutan pertama, pertahankan provider lama untuk pembacaan, dan restart kube-apiserver satu per satu. Setelah setiap perubahan, verifikasi pembacaan dan penulisan API, permintaan bersamaan, dan output audit. Jangan pernah me-restart seluruh control plane secara bersamaan. Buat versi konfigurasi dan plugin untuk rollback.

4. Tulis ulang objek historis

Mengubah urutan provider hanya memengaruhi penulisan di masa mendatang. Lakukan pembaruan no-op secara bertahap (batch) untuk Secret dan sumber daya terlindungi lainnya, atau gunakan migrasi storage-version untuk memicu penulisan ulang; coba lagi jika terjadi konflik. Bagi berdasarkan namespace (shard), batasi laju kerja (rate-limit), dan catat versi objek agar server API, etcd, dan KMS tidak kewalahan.

5. Kumpulkan bukti enkripsi

Buat Secret baru, baca byte mentahnya dari etcd, dan verifikasi prefiks enkripsi KMS v2; kemudian baca melalui API dan bandingkan dengan teks biasa. Ambil sampel objek lama dan setiap jenis sumber daya yang dilindungi, hitung mana yang belum ditulis ulang. Pembacaan API yang berhasil saja tidak membuktikan bahwa nilai pada disk telah dienkripsi.

6. Rotasi, tangani kegagalan, dan rollback

Setelah rotasi KEK, pastikan KEK lama tetap tersedia untuk dekripsi, tulis ulang dalam batch, dan pantau kegagalan. Lakukan latihan untuk batas waktu KMS, kehilangan soket, rollback pada satu apiserver, dan peningkatan plugin. Jika tingkat kesalahan melewati ambang batas, jeda penulisan ulang dan pulihkan konfigurasi baca yang lama. Hapus provider lama hanya setelah jalur baru dan cakupan historis terbukti.

Contoh jawaban berkualitas tinggi

Saya akan memvalidasi plugin KMS v2, izin, latensi, dan perilaku kegagalan secara terisolasi. Di produksi, saya akan menempatkan KMS v2 di urutan pertama, mempertahankan provider lama sementara untuk pembacaan, dan me-roll kube-apiserver secara individual. Setelah penulisan baru terenkripsi, saya akan menulis ulang objek dalam batch sumber daya dan namespace yang dibatasi, mencatat kemajuan, konflik, dan percobaan ulang. Bukti akan mencakup pembacaan API, prefiks etcd, dan sampel objek historis. Hanya setelah cakupan selesai, saya akan menghapus provider lama. Rotasi dan kegagalan KMS memerlukan latihan simulasi, ambang batas, dan rollback yang terarah.

Kesalahan umum

• Mengubah konfigurasi tanpa menulis ulang objek lama → teks biasa historis tetap ada → lakukan pembaruan batch dan hitung penyelesaiannya.
• Me-restart semua apiserver secara bersamaan → pemadaman control-plane → lakukan roll satu per satu dan amati kesehatannya.
• Hanya melihat pembacaan API → enkripsi penyimpanan belum terbukti → periksa byte mentah etcd.
• Menghapus provider lama secara langsung → data lama tidak dapat didekripsi → tunggu migrasi dan pertahankan jendela rollback.
• Mengabaikan latensi dan caching KMS → lonjakan permintaan API membebani KMS → lakukan uji beban, batasi laju (rate-limit), dan pantau panggilan.

Pertanyaan lanjutan dan tanggapan

Apakah semua Secret baru aman setelah KMS v2 dikonfigurasi?

Penulisan baru menggunakan provider pertama, tetapi objek lama tidak berubah secara otomatis. Tulis ulang objek tersebut dan verifikasi dengan bukti etcd.

Bisakah penulisan dilanjutkan saat KMS tidak tersedia?

Ini bergantung pada caching dan konfigurasi plugin; jangan pernah mengasumsikan ketersediaan. Tentukan batas waktu (timeout), penolakan penulisan, peringatan, dan perilaku coba lagi pasca-pemulihan, lalu latih skenario tersebut.

Mengapa mempertahankan provider lama berisiko dan bukan solusi permanen?

Langkah ini menjaga kemampuan dekripsi selama migrasi dan rollback, tetapi memperluas cakupan kunci dan konfigurasi. Hapus setelah cakupan terbukti, dengan tetap menyimpan bukti rotasi dan pemulihan.