Wawancara system design: Bagaimana cara memigrasikan keamanan Pod Kubernetes ke enforce dengan aman?

Petunjuk dan cakupan

Tim platform harus memindahkan namespace ke tingkat restricted dari Kubernetes Pod Security Standards. Beban kerja berasal dari layanan produksi, infrastruktur bersama, dan pekerjaan build sementara. Rancang proses discovery, remediasi, pengecualian, cutover, dan rollback.

Apa yang sedang diuji oleh pewawancara

• Pemahaman tentang perbedaan efek samping dari enforce, audit, dan warn.
• Menyatukan namespace, beban kerja, dan pengecualian ke dalam satu batas tata kelola.
• Menggunakan observasi untuk mendorong remediasi alih-alih langsung menolak semuanya.
• Mempertimbangkan versi kebijakan yang dipin, jejak audit, dan rollback darurat.

Pertanyaan klarifikasi

1. Versi Kubernetes, batasan tenant, dan alat rilis apa yang digunakan?
2. Apakah targetnya baseline atau restricted, dan bolehkah namespace menggunakan level yang berbeda?
3. Beban kerja mana yang memerlukan hak istimewa, hostPath, atau jaringan host?
4. Apakah rollback berarti menurunkan satu kebijakan untuk sementara atau mengalihkan lalu lintas ke kluster lama?

Jawaban 30 detik

Mulai per namespace dengan audit dan warn untuk mengumpulkan pelanggaran dan memberikan umpan balik yang dapat ditindaklanjuti kepada pengirim; jangan aktifkan enforce global terlebih dahulu. Lakukan remediasi berdasarkan urutan risiko dan bisnis dengan versi kebijakan yang dipin. Setiap pengecualian memerlukan pemilik, alasan, batas kedaluwarsa, dan kontrol kompensasi. Setelah uji coba skala kecil, aktifkan enforce namespace demi namespace dan pantau tingkat penolakan serta keberhasilan rilis. Rollback darurat hanya menurunkan kebijakan namespace yang terdampak sambil tetap mempertahankan jejak audit.

Desain langkah demi langkah

1. Menetapkan dasar aset dan kebijakan

Inventarisasi namespace, templat Pod, pengontrol, dan sumber rilis. Kelompokkan produksi, infrastruktur bersama, pengembangan, dan pekerjaan sementara. Pilih tingkat target dan versi untuk setiap grup, lalu catat pengecualian; namespace tanpa label adalah celah keamanan, bukan default yang aman.

2. Amati sebelum memblokir

Aktifkan audit untuk mencatat pelanggaran dan tingkat yang sama di warn untuk umpan balik klien. Agregasikan peristiwa berdasarkan aturan, tim, dan image ke dalam antrean remediasi. Ini mengungkap risiko tanpa mengganggu lalu lintas saat ini.

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

3. Remediasi beban kerja

Hapus hak istimewa yang tidak perlu, hostNetwork, hostPID, hostPath, dan sistem berkas root yang dapat ditulis. Tambahkan pembatasan non-root, seccomp, dan capability. Tempatkan pemeriksaan kebijakan di CI sehingga templat gagal dengan bidang tertentu sebelum kluster menolaknya.

4. Kelola pengecualian

Berikan pengecualian hanya pada namespace yang dapat dikelola atau titik masuk yang terkontrol. Catat dampak, pemilik, batas kedaluwarsa, dan kontrol kompensasi. Pengecualian admisi bukanlah daftar izin permanen; perpanjangan memerlukan peninjauan, dan namespace sistem tidak boleh semuanya dikecualikan tanpa syarat.

5. Cutover ke enforce secara bertahap

Aktifkan enforce terlebih dahulu untuk namespace berisiko rendah. Bandingkan tingkat penolakan, kegagalan rilis, restart, dan keluhan tenant sebelum memperluas penerapan. Pin versi kebijakan; latih pembaruan di warn dan audit agar perubahan latest tidak menimbulkan gelombang penolakan yang mengejutkan.

6. Rollback dan verifikasi

Pengontrol rilis harus dapat menjeda dan memulihkan templat lama. Jika layanan inti terblokir, turunkan tingkat kebijakan hanya untuk namespace tersebut untuk sementara sambil mempertahankan audit dan peristiwa. Uji Pod baru, templat Deployment, pembaruan bergulir, Job, kedaluwarsa pengecualian, dan peningkatan versi kebijakan.

Model jawaban berkualitas tinggi

Saya akan menginventarisasi namespace dan beban kerja, mem-pin versi kebijakan, lalu mengumpulkan pelanggaran dengan audit beserta warn pada tingkat yang sama. CI memeriksa konteks keamanan lebih awal, sementara pengecualian memiliki pemilik dan tanggal kedaluwarsa. Namespace berisiko rendah beralih ke enforce terlebih dahulu; saya hanya memperluas setelah tingkat penolakan, keberhasilan rilis, dan kesalahan bisnis tetap dapat diterima. Pembaruan kebijakan dilatih dengan warn/audit. Jika suatu layanan terblokir, saya hanya me-rollback kebijakan namespace tersebut, mempertahankan jejak audit, dan memperbaiki akar masalah alih-alih melemahkan kluster secara permanen.

Kesalahan umum

• Mengaktifkan enforce global secara langsung → banyak rilis gagal bersamaan → gunakan audit/warn dan tahapan.
• Memperlakukan namespace tanpa label sebagai aman → cakupan kebijakan memiliki blind spot → beri label dan lakukan inventarisasi.
• Membuat pengecualian permanen → risiko tetap tersembunyi → wajibkan kedaluwarsa dan peninjauan.
• Menemukan pelanggaran hanya di kluster → umpan balik datang terlambat → pindahkan pemeriksaan ke CI dan tinjauan templat.
• Menggunakan latest tanpa latihan → perubahan versi menyebabkan penolakan mendadak → pin dan amati terlebih dahulu.

Pertanyaan lanjutan dan tanggapan

Mengapa mengaktifkan warn dan audit jika keduanya tidak memblokir?

warn memberikan umpan balik langsung kepada klien yang mengirimkan permintaan; audit mencatat pelanggaran untuk pengukuran platform. Keduanya mendukung alur kerja yang berbeda dan tidak saling menggantikan.

Haruskah pengecualian dicakupkan ke Pod atau namespace?

Lebih disukai batasan namespace yang dapat dikelola dengan titik masuk yang terkontrol. Izin per Pod mudah disalin dan dilewati; semua pengecualian tetap memerlukan pemilik, batas kedaluwarsa, dan kontrol kompensasi.

Bagaimana Anda membuktikan ketersediaan tidak menurun?

Bandingkan penolakan, keberhasilan rilis, restart, SLO, dan kesalahan tenant sebelum dan sesudah setiap tahap. Jalankan ulang pembaruan bergulir dan Job berumur pendek serta layanan yang berjalan lama.