Masalah dan konteks
Kubernetes ValidatingAdmissionPolicy mengevaluasi ekspresi CEL terhadap permintaan API. Definisi kebijakan dipasangkan dengan binding yang memilih sumber daya dan menentukan tindakan penegakan. Ini menyediakan jalur validasi native-cluster, tetapi kebijakan dengan cakupan yang buruk atau tidak tersedia dapat menolak operasi pemulihan yang sah.
Asumsikan namespace produksi telah diberi label, asal-usul (provenance) image tersedia sebagai field admisi, dan engineer platform memiliki kebijakan tersebut. Desain harus membedakan aturan keamanan yang ketat dari peringatan, mendukung uji coba (dry run), dan mempertahankan jalur darurat yang diaudit.
Hal yang dievaluasi oleh pewawancara
Pewawancara mencari pemisahan antara definisi kebijakan dan binding, perilaku kegagalan yang eksplisit, pencocokan sumber daya yang sempit, dan model pengecualian yang dapat diuji. Jawaban yang kuat membahas pemeriksaan tipe CEL, peluncuran berversi, metrik audit, dan apa yang terjadi ketika mesin kebijakan atau data yang dirujuk tidak tersedia.
Jawaban biasa hanya menulis satu ekspresi yang menolak YAML yang buruk. Jawaban yang kuat menjelaskan cakupan, tingkat tindakan, kompatibilitas, observabilitas, dan rollback.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Grup API, versi, namespace, dan operasi mana yang masuk dalam cakupan?
- Apakah aturannya tentang identitas image, penguncian digest, akses host, atau semuanya?
- Apakah pelanggaran harus ditolak (deny), diberi peringatan (warn), atau hanya diaudit (audit) selama masa uji coba?
- Pengontrol atau namespace sistem mana yang memerlukan pengecualian, dan siapa yang menyetujuinya?
- Apa jalur pemulihan jika kebijakan memblokir perbaikan insiden?
Jika aturan bergantung pada status eksternal yang tidak dapat diakses CEL secara andal, pertahankan kebijakan tetap lokal dan gunakan pengontrol terpisah untuk pemeriksaan yang lebih kaya. Jika pengecualian terlalu luas, kebijakan dapat memberikan rasa aman yang palsu.
Jawaban 30 detik
“Saya akan mendefinisikan aturan CEL kecil bertipe data dan mengikatnya hanya ke beban kerja produksi dan operasi yang relevan. Saya akan mulai dalam mode audit atau peringatan, mengukur pelanggaran berdasarkan pemilik, lalu menegakkan satu aturan pada satu waktu. Pengecualian akan dibatasi secara sempit dan diaudit, dengan jalur darurat yang teruji. Saya akan memantau latensi admisi, tingkat penolakan, dan keberhasilan pemulihan, serta melakukan rollback binding jika perilaku kebijakan tidak aman.”
Desain langkah demi langkah
- Definisikan invarian. Tulis aturan terpisah untuk registry image yang disetujui, persyaratan digest, dan hak istimewa host. Hindari satu ekspresi tunggal yang sulit diuji atau dijelaskan.
- Periksa tipe dan uji CEL. Validasi ekspresi terhadap skema sumber daya target, termasuk field yang hilang, daftar, pembaruan, dan operasi penghapusan. Simpan fixture dalam alur kerja peninjauan kebijakan.
- Tentukan cakupan dengan binding. Cocokkan hanya namespace produksi, jenis beban kerja, dan operasi yang memerlukan perlindungan. Binding yang terpisah memungkinkan tim mengadopsi aturan secara independen.
- Pilih penegakan. Mulai dengan audit atau peringatan, tingkatkan ke penolakan (deny) setelah pemilik memperbaiki pelanggaran, dan catat tindakan tersebut dalam riwayat perubahan.
- Rancang pengecualian. Berikan pengecualian hanya pada identitas sistem atau namespace yang ditentukan, wajibkan masa kedaluwarsa atau catatan persetujuan, dan berikan peringatan (alert) saat pengecualian digunakan.
- Rollback dengan aman. Pertahankan definisi kebijakan dengan versi, nonaktifkan binding daripada menghapus riwayat, dan verifikasi bahwa Deployment darurat dapat berjalan di bawah jalur yang terdokumentasi.
Alternatifnya mencakup webhook validasi untuk data eksternal atau mutasi plus validasi untuk normalisasi. Gunakan kebijakan bawaan untuk invarian lokal dan deterministik yang harus ditegakkan dekat dengan server API.
Contoh jawaban
“Saya akan membuat tiga kebijakan: allow-list registry, kewajiban digest, dan pelarangan hostNetwork untuk Deployment produksi. Setiap binding hanya akan memilih namespace produksi yang berlabel. Uji coba berjalan dalam mode audit selama satu minggu; pemilik menerima laporan pelanggaran, dan kami memperbaiki positif palsu sebelum mengaktifkan deny. Identitas platform dan break-glass adalah satu-satunya pengecualian, dengan masa kedaluwarsa dan peristiwa audit. Kami memberi peringatan pada latensi admisi dan perubahan pemulihan yang ditolak, serta melakukan rollback dengan menonaktifkan binding jika suatu insiden mengungkap adanya aturan yang tidak aman.”
Kesalahan umum
- Kesalahan: Mencocokkan setiap namespace dan operasi → Mengapa gagal: pengontrol sistem dan jalur pemulihan terblokir → Solusi: batasi cakupan binding secara sempit.
- Kesalahan: Memperlakukan peringatan sebagai penegakan → Mengapa gagal: pengguna menganggap keamanan terjamin → Solusi: komunikasikan tingkat tindakan dan kriteria promosi.
- Kesalahan: Menggunakan CEL tanpa tipe pada field yang hilang → Mengapa gagal: pembaruan dan versi API lama berperilaku berbeda → Solusi: periksa tipe dan uji kasus field yang tidak ada.
- Kesalahan: Membuat pengecualian permanen → Mengapa gagal: bypass menjadi kebijakan yang sebenarnya → Solusi: wajibkan masa kedaluwarsa, pemilik, dan audit.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika ekspresi kebijakan memiliki kesalahan sintaks?
Kubernetes memvalidasi definisi kebijakan dan melaporkan kesalahan daripada menerima ekspresi yang tidak valid. Tetap jalankan melalui fixture peninjauan dan pertahankan binding dalam mode audit sampai perilakunya terkonfirmasi.
Bagaimana Anda menangani aturan yang membutuhkan basis data kerentanan eksternal?
Jangan berpura-pura bahwa CEL dapat mengambil status eksternal arbitrer. Gunakan pengontrol atau webhook yang mengelola kesegaran data, batas waktu (timeout), dan semantik kegagalan, sambil tetap mempertahankan invarian lokal dalam kebijakan bawaan.
Bagaimana engineer on-call dapat memulihkan sistem ketika aturan deny memblokir perbaikan?
Sediakan identitas break-glass atau namespace yang sempit dan diaudit dengan masa kedaluwarsa, dokumentasikan persetujuan, dan berikan peringatan saat digunakan. Uji jalur tersebut sebelum penegakan dilakukan.
Kapan Anda akan menghapus kebijakan tersebut?
Hapus atau nonaktifkan binding ketika positif palsu tetap tinggi, latensi admisi mengancam server API, atau invarian telah dipindahkan ke kontrol yang lebih kuat. Pertahankan riwayat dan metrik untuk pengambilan keputusan tersebut.