Temu duga reka bentuk sistem: Bagaimanakah anda memindahkan keselamatan Pod Kubernetes ke enforce dengan selamat?

Gesaan dan skop

Pasukan platform mesti memindahkan ruang nama ke tahap restricted bagi Kubernetes Pod Security Standards. Beban kerja datang daripada perkhidmatan pengeluaran, infrastruktur kongsi dan kerja binaan sementara. Reka bentuk penemuan, pemulihan, pengecualian, peralihan (cutover) dan rollback.

Perkara yang diuji oleh penemu duga

• Memahami kesan sampingan yang berbeza bagi enforce, audit dan warn.
• Membawa ruang nama, beban kerja dan pengecualian ke dalam satu sempadan tadbir urus.
• Menggunakan pemerhatian untuk memacu pemulihan dan bukannya menolak segala-galanya serta-merta.
• Mempertimbangkan versi dasar yang dipin, jejak audit dan rollback kecemasan.

Soalan penjelasan

1. Apakah versi Kubernetes, sempadan penyewa dan alat pelepasan yang sedang digunakan?
2. Adakah sasarannya baseline atau restricted, dan bolehkah ruang nama menggunakan tahap yang berbeza?
3. Beban kerja manakah yang memerlukan keistimewaan (privileges), hostPath atau rangkaian hos?
4. Adakah rollback bermaksud menurunkan satu dasar secara sementara atau mengalihkan trafik ke kluster lama?

Jawapan 30 saat

Mulakan bagi setiap ruang nama dengan audit dan warn untuk mengumpul pelanggaran dan memberi maklum balas yang boleh diambil tindakan kepada penghantar; jangan hidupkan enforce global terlebih dahulu. Pulihkan mengikut urutan risiko dan perniagaan dengan versi dasar yang dipin. Setiap pengecualian memerlukan pemilik, sebab, tarikh luput dan kawalan pampasan. Selepas percubaan rintis kecil, dayakan enforce ruang nama demi ruang nama dan perhatikan kadar penolakan serta kejayaan pelepasan. Rollback kecemasan hanya menurunkan dasar ruang nama yang terjejas sambil mengekalkan jejak audit.

Reka bentuk langkah demi langkah

1. Wujudkan garis dasar aset dan dasar

Inventori ruang nama, templat Pod, pengawal dan sumber pelepasan. Kumpulkan pengeluaran, infrastruktur kongsi, pembangunan dan kerja sementara. Pilih tahap sasaran dan versi untuk setiap kumpulan, dan rekodkan pengecualian; ruang nama tanpa label ialah jurang keselamatan, bukan tetapan lalai yang selamat.

2. Perhatikan sebelum menyekat

Dayakan audit untuk merekodkan pelanggaran dan tahap yang sama dalam warn untuk maklum balas klien. Agregatkan peristiwa mengikut peraturan, pasukan dan imej ke dalam baris gilir pemulihan. Ini mendedahkan risiko tanpa mengganggu trafik semasa.

metadata:
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

3. Pulihkan beban kerja

Alih keluar keistimewaan yang tidak perlu, hostNetwork, hostPID, hostPath dan sistem fail punca yang boleh ditulis. Tambahkan sekatan non-root, seccomp dan capability. Letakkan semakan dasar dalam CI supaya templat gagal dengan medan tertentu sebelum kluster menolaknya.

4. Tadbir pengecualian

Berikan pengecualian hanya pada ruang nama yang boleh ditadbir atau titik masuk yang terkawal. Rekodkan impak, pemilik, tarikh luput dan kawalan pampasan. Pengecualian kemasukan bukanlah senarai dibenarkan yang kekal; pembaharuan memerlukan semakan, dan ruang nama sistem tidak sepatutnya dikecualikan secara tanpa syarat.

5. Lakukan cutover enforce secara berperingkat

Dayakan enforce terlebih dahulu untuk ruang nama berisiko rendah. Bandingkan kadar penolakan, kegagalan pelepasan, mula semula dan aduan penyewa sebelum memperluaskannya. Pin versi dasar; latih naik taraf dalam warn dan audit supaya perubahan latest tidak menimbulkan gelombang penolakan yang mengejutkan.

6. Rollback dan sahkan

Pengawal pelepasan mesti menjeda dan memulihkan templat lama. Jika perkhidmatan teras disekat, turunkan sementara hanya dasar ruang nama tersebut sambil mengekalkan audit dan peristiwa. Uji Pod baharu, templat Deployment, peningkatan berperingkat (rolling upgrades), Jobs, luputnya pengecualian dan peningkatan versi dasar.

Model jawapan berkualiti tinggi

Saya akan menginventorikan ruang nama dan beban kerja, memin versi dasar, kemudian mengumpul pelanggaran dengan audit berserta warn pada tahap yang sama. CI menyemak konteks keselamatan lebih awal, manakala pengecualian membawa pemilik dan tarikh luput. Ruang nama berisiko rendah beralih ke enforce terlebih dahulu; saya hanya memperluaskannya selepas kadar penolakan, kejayaan pelepasan dan ralat perniagaan kekal pada tahap yang boleh diterima. Peningkatan dasar dilatih dengan warn/audit. Jika perkhidmatan disekat, saya hanya melancarkan rollback bagi dasar ruang namanya, mengekalkan jejak audit dan membetulkan punca utama dan bukannya melemahkan kluster secara kekal.

Kesilapan lazim

• Mendayakan enforce global serta-merta → banyak pelepasan gagal serentak → gunakan audit/warn dan peringkat.
• Menganggap ruang nama tanpa label sebagai selamat → liputan dasar mempunyai titik buta → labelkan dan inventorikannya.
• Mencipta pengecualian kekal → risiko kekal tersembunyi → wajibkan tarikh luput dan semakan.
• Menemui pelanggaran hanya dalam kluster → maklum balas tiba terlalu lewat → alihkan semakan ke dalam CI dan semakan templat.
• Menggunakan latest tanpa latihan → perubahan versi menyebabkan penolakan mengejut → pin dan perhatikan terlebih dahulu.

Soalan susulan dan jawapan

Mengapa mendayakan kedua-dua warn dan audit jika kedua-duanya tidak menyekat?

warn memberikan maklum balas segera kepada klien yang menyerahkan; audit merekodkan pelanggaran untuk pengukuran platform. Kedua-duanya menyokong aliran kerja yang berbeza dan tidak menggantikan antara satu sama lain.

Patutkah pengecualian diskopkan kepada Pod atau ruang nama?

Utamakan sempadan ruang nama yang boleh ditadbir dengan titik masuk yang terkawal. Kebenaran bagi setiap Pod mudah disalin dan dipintas; semua pengecualian masih memerlukan pemilik, tarikh luput dan kawalan pampasan.

Bagaimanakah anda membuktikan ketersediaan tidak menurun?

Bandingkan penolakan, kejayaan pelepasan, mula semula, SLO dan ralat penyewa sebelum dan selepas setiap peringkat. Mainkan semula peningkatan berperingkat dan Jobs jangka pendek serta perkhidmatan jangka panjang.