Temu duga reka bentuk sistem: Bagaimanakah anda memindahkan Kubernetes ke KMS v2 dan membuktikan Secret disulitkan?

Gesaan dan skop

Pasukan platform mesti melindungi Secret dalam etcd. Kluster mempunyai beberapa kube-apiserver, pemalam KMS luaran, dan banyak objek bersejarah, namun pelepasan tidak boleh terhenti semasa migrasi. Reka bentuk konfigurasi, putaran kunci, penulisan semula, pengesahan, pemantauan, dan pemulihan balik (rollback).

Perkara yang diuji oleh penemu duga

• Memahami sempadan envelope encryption KMS v2 dan hubungan DEK/KEK.
• Membezakan penulisan baharu yang disulitkan daripada objek bersejarah yang ditulis semula.
• Mengendalikan pelbagai apiserver, gangguan KMS, putaran kunci, dan kemas kini serentak (concurrent updates).
• Membuktikan hasil dengan bukti etcd dan bacaan API berbanding perbezaan konfigurasi (config diff) semata-mata.

Soalan penjelasan

1. Versi Kubernetes dan pemalam yang manakah, serta topologi ketersediaan tinggi yang digunakan?
2. Sumber manakah yang dilindungi, termasuk sumber tersuai dan log audit?
3. Apakah jaminan ketersediaan, kependaman (latency), putaran kunci, dan pemulihan bencana yang disediakan oleh KMS luaran?
4. Apakah tetingkap satah kawalan, tarikh akhir pemulihan balik, dan format bukti pematuhan yang diperlukan?

Jawapan 30 saat

Sahkan pemalam KMS v2 dan kebenaran dalam kluster bukan pengeluaran. Jadikan KMS sebagai penyedia (provider) pertama, kekalkan penyedia lama sebagai sandaran bacaan, dan lakukan pelancaran berperingkat (rolling update) bagi setiap kube-apiserver satu demi satu. Penulisan baharu akan disulitkan, tetapi objek bersejarah memerlukan kemas kini no-op atau migrasi storage-version. Sahkan bacaan API, awalan etcd, metrik KMS, latihan kegagalan, dan rekod audit. Alih keluar penyedia lama hanya selepas setiap objek ditulis semula dan tetingkap pemulihan balik telah tamat.

Reka bentuk langkah demi langkah

1. Tentukan model penyulitan

Kubernetes menggunakan penyulitan sampul (envelope encryption): kunci penyulitan data (DEK) melindungi sumber, manakala kunci penyulitan kunci (KEK) dilindungi oleh KMS luaran. KMS v2 mengurangkan overhed permintaan dengan caching bahagian pelayan dan reka bentuk DEK bagi setiap apiserver, tetapi ia tidak menulis semula setiap nilai lama etcd secara automatik.

2. Sahkan pemalam dan kebenaran terlebih dahulu

Dalam kluster terpencil, uji soket, identiti, masa tamat (timeouts), mula semula, dan tingkah laku semasa KMS tidak tersedia. Sahkan bahawa kube-apiserver boleh menyahsulit objek yang ditulis oleh penyedia lama dan menulis Secret baharu melalui penyedia baharu. Rekod kependaman, ralat, hit cache, dan jumlah 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 pelancaran satah kawalan ketersediaan tinggi

Letakkan KMS di tempat pertama, kekalkan penyedia lama untuk bacaan, dan mulakan semula kube-apiserver satu demi satu. Selepas setiap perubahan, sahkan bacaan dan penulisan API, permintaan serentak, dan output audit. Jangan sekali-kali memulakan semula keseluruhan satah kawalan secara serentak. Buat versi bagi konfigurasi dan pemalam untuk tujuan pemulihan balik.

4. Tulis semula objek bersejarah

Mengubah susunan penyedia hanya mempengaruhi penulisan masa hadapan. Lakukan kemas kini no-op secara berkelompok untuk Secret dan sumber lain yang dilindungi, atau gunakan migrasi storage-version untuk mencetuskan penulisan semula; cuba semula jika berlaku konflik. Bahagikan mengikut namespace (shard), hadkan kadar kerja (rate-limit), dan rekod versi objek supaya pelayan API, etcd, dan KMS tidak terbeban.

5. Kumpulkan bukti penyulitan

Cipta Secret baharu, baca bait mentahnya daripada etcd, dan sahkan awalan penyulitan KMS v2; kemudian baca melalui API dan bandingkan teks biasa. Ambil sampel objek lama dan setiap jenis sumber yang dilindungi, kira objek yang belum ditulis semula. Kejayaan membaca API sahaja tidak membuktikan nilai pada cakera telah disulitkan.

6. Putar kunci, uji kegagalan, dan lakukan pemulihan balik

Selepas putaran KEK, pastikan KEK lama tersedia untuk nyahsulit, tulis semula secara berkelompok, dan pantau kegagalan. Latih tubi senario masa tamat KMS, kehilangan soket, pemulihan balik satu apiserver, dan naik taraf pemalam. Jika kadar ralat melepasi ambang batas, jedakan penulisan semula dan pulihkan konfigurasi bacaan lama. Alih keluar penyedia lama hanya selepas laluan baharu dan liputan sejarah terbukti.

Model jawapan berkualiti tinggi

Saya akan mengesahkan pemalam KMS v2, kebenaran, kependaman, dan tingkah laku kegagalan secara berasingan. Pengeluaran akan meletakkan KMS v2 di tempat pertama, mengekalkan penyedia lama seketika untuk bacaan, dan melancarkan kube-apiserver secara individu. Sebaik sahaja penulisan baharu disulitkan, saya akan menulis semula objek dalam kelompok sumber dan namespace yang terhad, sambil merekodkan kemajuan, konflik, dan percubaan semula. Bukti akan merangkumi bacaan API, awalan etcd, dan sampel objek bersejarah. Hanya selepas liputan selesai, saya akan mengalih keluar penyedia lama. Putaran kunci dan kegagalan KMS memerlukan latihan, ambang batas, dan pemulihan balik yang terhad.

Kesilapan lazim

• Menukar konfigurasi tanpa menulis semula objek lama → teks biasa bersejarah kekal → buat kemas kini kelompok dan kira penyelesaian.
• Memulakan semula semua apiserver serentak → gangguan satah kawalan → lancarkan satu demi satu dan perhatikan kesihatan sistem.
• Hanya melihat bacaan API → penyulitan storan tidak terbukti → periksa bait mentah etcd.
• Mengalih keluar penyedia lama serta-merta → data lama tidak dapat dinyahsulit → tunggu migrasi dan kekalkan tetingkap pemulihan balik.
• Mengabaikan kependaman dan caching KMS → permintaan puncak API membebankan KMS → lakukan ujian beban, hadkan kadar, dan pantau panggilan.

Soalan susulan dan jawapan

Adakah semua Secret baharu selamat selepas KMS v2 dikonfigurasikan?

Penulisan baharu menggunakan penyedia pertama, tetapi objek lama tidak berubah secara automatik. Tulis semula objek tersebut dan sahkan dengan bukti etcd.

Bolehkah penulisan diteruskan semasa KMS tidak tersedia?

Ia bergantung pada caching dan konfigurasi pemalam; jangan sekali-kali menganggap ketersediaan sentiasa ada. Tentukan masa tamat, penolakan penulisan, amaran, dan tingkah laku percubaan semula selepas pemulihan, kemudian lakukan latihan mengenainya.

Mengapakah mengekalkan penyedia lama merupakan risiko dan bukannya penyelesaian kekal?

Ia mengekalkan kebolehan nyahsulit semasa migrasi dan pemulihan balik tetapi meluaskan skop kunci dan konfigurasi. Alih keluar selepas liputan terbukti, sambil mengekalkan bukti putaran dan pemulihan.