Masalah dan konteks
Kubernetes ValidatingAdmissionPolicy menilai ungkapan CEL terhadap permintaan API. Definisi dasar dipadankan dengan pengikatan (binding) yang memilih sumber dan mentakrifkan tindakan penguatkuasaan. Ini memberikan laluan pengesahan natif kluster, tetapi dasar dengan skop yang tidak betul atau tidak tersedia boleh menolak operasi pemulihan yang sah.
Andaikan ruang nama pengeluaran dilabelkan, asal-usul imej tersedia sebagai medan kemasukan, dan jurutera platform memiliki dasar tersebut. Reka bentuk mesti membezakan peraturan keselamatan tegar daripada amaran, menyokong larian percubaan (dry runs), dan mengekalkan laluan kecemasan yang diaudit.
Perkara yang dinilai oleh penemu duga
Penemu duga mencari pemisahan antara definisi dasar dan pengikatan, tingkah laku kegagalan yang jelas, pemadanan sumber yang sempit, dan model pengecualian yang boleh diuji. Jawapan yang kukuh membincangkan pemeriksaan jenis CEL, pelancaran berversi, metrik audit, dan apa yang berlaku apabila enjin dasar atau data yang dirujuk tidak tersedia.
Jawapan biasa menulis satu ungkapan yang menolak YAML yang tidak elok. Jawapan yang kukuh menerangkan skop, tahap tindakan, keserasian, kebolehlihatan dan pengunduran (rollback).
Soalan untuk dijelaskan terlebih dahulu
- Kumpulan API, versi, ruang nama dan operasi manakah yang berada dalam skop?
- Adakah peraturan tersebut mengenai identiti imej, penetapan daijes (digest pinning), akses hos, atau kesemuanya?
- Patutkah pelanggaran menolak (deny), memberi amaran (warn), atau hanya mengaudit (audit) semasa fasa perintis?
- Pengawal atau ruang nama sistem manakah yang memerlukan pengecualian, dan siapa yang meluluskannya?
- Apakah laluan pemulihan jika dasar menyekat pembetulan insiden?
Jika peraturan bergantung pada keadaan luaran yang tidak dapat diakses oleh CEL secara boleh dipercayai, kekalkan dasar secara setempat dan gunakan pengawal berasingan untuk pemeriksaan yang lebih terperinci. Jika pengecualian terlalu luas, dasar tersebut mungkin memberikan keyakinan palsu.
Jawapan 30 saat
"Saya akan mentakrifkan peraturan CEL yang kecil dan ditaip serta mengikatnya hanya pada beban kerja pengeluaran dan operasi yang berkaitan. Saya akan bermula dalam mod audit atau amaran, mengukur pelanggaran mengikut pemilik, kemudian menguatkuasakan satu peraturan pada satu masa. Pengecualian adalah sempit dan diaudit, dengan laluan kecemasan yang telah diuji. Saya akan memantau kependaman kemasukan, kadar penolakan dan kejayaan pemulihan, serta mengundurkan (rollback) pengikatan jika tingkah laku dasar tidak selamat."
Reka bentuk langkah demi langkah
- Takrifkan tak varian (invariant). Tulis peraturan berasingan untuk pendaftaran imej yang diluluskan, keperluan daijes dan keistimewaan hos. Elakkan satu ungkapan yang sukar diuji atau dijelaskan.
- Semak jenis dan uji CEL. Sahkan ungkapan terhadap skema sumber yang disasarkan, termasuk medan yang tiada, senarai, kemas kini dan operasi pemadaman. Simpan lekapan (fixtures) dalam aliran kerja semakan dasar.
- Skopkan dengan pengikatan (binding). Padankan hanya ruang nama pengeluaran, jenis beban kerja dan operasi yang memerlukan perlindungan. Pengikatan yang berasingan membolehkan pasukan menerima pakai peraturan secara bebas.
- Pilih penguatkuasaan. Mulakan dengan audit atau amaran, tingkatkan kepada penolakan (deny) selepas pemilik memulihkan pelanggaran, dan rekodkan tindakan tersebut dalam sejarah perubahan.
- Reka bentuk pengecualian. Kecualikan hanya identiti atau ruang nama sistem yang dinamakan, wajibkan rekod tamat tempoh atau kelulusan, dan beri amaran apabila pengecualian digunakan.
- Undur semula (rollback) dengan selamat. Kekalkan definisi dasar yang berversi, nyahdayakan pengikatan dan bukannya memadamkan sejarah, dan sahkan bahawa Deployment kecemasan boleh diteruskan di bawah laluan yang didokumenkan.
Alternatif termasuk webhook pengesahan untuk data luaran atau mutasi serta pengesahan untuk penyeragaman. Gunakan dasar terbina dalam untuk tak varian setempat yang deterministik yang mesti dikuatkuasakan berhampiran dengan pelayan API.
Contoh jawapan
"Saya akan mencipta tiga dasar: senarai dibenarkan pendaftaran, daijes diperlukan dan hostNetwork dilarang untuk Deployment pengeluaran. Setiap pengikatan hanya akan memilih ruang nama pengeluaran yang dilabelkan. Fasa perintis berjalan dalam mod audit selama satu minggu; pemilik menerima laporan pelanggaran, dan kami membetulkan positif palsu sebelum mendayakan penolakan (deny). Identiti platform dan 'break-glass' adalah satu-satunya pengecualian, dengan tarikh tamat tempoh dan peristiwa audit. Kami memberi amaran mengenai kependaman kemasukan dan perubahan pemulihan yang ditolak, dan berundur semula dengan menyahdayakan pengikatan jika insiden mendedahkan peraturan yang tidak selamat."
Kesilapan biasa
- Kesilapan: Memadankan setiap ruang nama dan operasi → Sebab ia gagal: pengawal sistem dan laluan pemulihan disekat → Penyelesaian: skopkan pengikatan secara sempit.
- Kesilapan: Menganggap amaran sebagai penguatkuasaan → Sebab ia gagal: pengguna menganggap keselamatan dijamin → Penyelesaian: sampaikan tahap tindakan dan kriteria peningkatan.
- Kesilapan: Menggunakan CEL yang tidak ditaip pada medan yang tiada → Sebab ia gagal: kemas kini dan versi API lama berkelakuan berbeza → Penyelesaian: semak jenis dan uji kes medan yang tiada.
- Kesilapan: Menjadikan pengecualian kekal → Sebab ia gagal: pintasan menjadi dasar yang sebenar → Penyelesaian: wajibkan tarikh tamat tempoh, pemilik dan audit.
Soalan susulan dan respons
Bagaimana jika ungkapan dasar mempunyai ralat sintaks?
Kubernetes mengesahkan definisi dasar dan melaporkan ralat dan bukannya menerima ungkapan yang tidak sah. Tetap jalankannya melalui lekapan semakan dan kekalkan pengikatan dalam mod audit sehingga tingkah laku disahkan.
Bagaimanakah anda mengendalikan peraturan yang memerlukan pangkalan data kerentanan luaran?
Jangan berpura-pura bahawa CEL boleh mengambil keadaan luaran sewenang-wenangnya. Gunakan pengawal atau webhook yang menguruskan kesegaran, masa tamat (timeout) dan semantik kegagalan, sambil mengekalkan tak varian setempat dalam dasar terbina dalam.
Bagaimanakah jurutera bertugas (on-call) boleh pulih apabila peraturan penolakan (deny) menyekat pembetulan?
Sediakan identiti 'break-glass' atau ruang nama yang sempit dan diaudit dengan tarikh tamat tempoh, dokumentasikan kelulusan, dan beri amaran semasa penggunaan. Uji laluan tersebut sebelum penguatkuasaan.
Bilakah anda akan mengalih keluar dasar tersebut?
Alih keluar atau nyahdayakan pengikatan apabila positif palsu kekal tinggi, kependaman kemasukan mengancam pelayan API, atau tak varian telah beralih kepada kawalan yang lebih kukuh. Kekalkan sejarah dan metrik untuk keputusan tersebut.