Temu duga reka bentuk sistem: Lindungi dasar kemasukan Kubernetes dengan kawalan berasaskan manifes

Gesaan dan skop

Ini ialah soalan reka bentuk sistem untuk jurutera keselamatan platform. Kubernetes v1.36 memperkenalkan kawalan kemasukan berasaskan manifes sebagai ciri alfa. Dasar dimuatkan daripada direktori setempat pelayan API sebelum permintaan diservis, jadi reka bentuk mesti berfungsi sebelum etcd tersedia dan mesti menyertakan laluan pemulihan berasaskan fail.

Perkara yang dinilai oleh penemu duga

Pemisahan antara dasar butstrap dan dasar yang diuruskan oleh API.
Pengesahan atomik, undur balik (rollback) dan tingkah laku permulaan gagal-pantas (fail-fast).
Perlindungan konfigurasi dasar dan webhook daripada pemadaman berkeistimewaan.
Pengedaran konfigurasi dan pengesanan hanyutan merentas tika pelayan API.
Laluan kecemasan (escape hatch) pengendali, kebolehauditan dan ujian mod kegagalan.

Sumber manakah yang dilindungi?

Jelaskan sama ada garis dasar hanya melindungi objek ValidatingAdmissionPolicy atau juga pengikatan (bindings), webhook dan konfigurasi mutasi. Peraturan pemadanan dan radius letupan (blast radius) berubah mengikut jawapan tersebut.

Apakah pihak berkuasa pemulihan?

Jika API tidak tersedia atau dasar menyekat pembaikannya sendiri, laluan berwibawa mestilah hos pelayan API atau saluran paip konfigurasinya yang tidak boleh diubah (immutable). Tentukan siapa yang boleh mengubah laluan tersebut dan cara perubahan disemak.

Berapakah bilangan pelayan API yang berjalan?

Setiap tika membaca failnya sendiri. Kumpulan pelayan (fleet) memerlukan artifak dialamatkan kandungan (content-addressed), penjadualan pelancaran dan metrik cincangan (hash) konfigurasi; satu pelayan boleh menggunakan pemerhati tempatan yang lebih mudah tetapi masih memerlukan penggantian atomik.

Rangka kerja jawapan 30 saat

"Saya akan memasang dasar manifes yang kecil dan disemak sebelum mendayakan sebarang dasar yang diuruskan oleh API. Ia menolak kemas kini atau pemadaman untuk sumber yang ditandakan sebagai dilindungi, dan namanya menggunakan akhiran simpanan .static.k8s.io. Setiap pelayan API menerima direktori berversi yang sama dan mendedahkan cincangan konfigurasinya. Perubahan fail disahkan dan ditukar secara atomik; kemas kini tidak sah mengekalkan versi baik yang terakhir, manakala permulaan tidak sah akan gagal dengan pantas. Pengendali pulih melalui laluan konfigurasi hos, bukan melalui API yang disekat."

Reka bentuk langkah demi langkah

Butstrap sempadan amanah

Dayakan ManifestBasedAdmissionControlConfig pada setiap pelayan API dan konfigurasikan staticManifestsDir melalui fail konfigurasi kemasukan sedia ada. Simpan manifes dalam artifak baca sahaja yang disahkan integritinya. Wajibkan setiap nama objek statik berakhir dengan .static.k8s.io supaya metrik dan rekod audit dapat membezakan objek bersandarkan fail daripada objek API.

yaml

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
  configuration:
    staticManifestsDir: /etc/kubernetes/admission/static

Tulis peraturan perlindungan

Dasar butstrap memadankan operasi UPDATE dan DELETE pada dasar kemasukan, pengikatan dan konfigurasi webhook. Ia menolak perubahan hanya apabila objek lama mempunyai label perlindungan seperti platform.example.com/protected=true. Ini mengekalkan keupayaan eksperimen biasa sambil melindungi garis dasar.

Jadikan kemas kini bersifat transaksi

Pelayan API mengesahkan set fail yang diubah dan menukarnya secara atomik. Jika pengesahan gagal semasa masa larian (runtime), kekalkan konfigurasi baik sebelumnya dan log ralat tersebut. Semasa permulaan, gagalkan proses sebelum melayani permintaan apabila mana-mana manifes tidak sah; memulakan secara senyap tanpa garis dasar akan mewujudkan jurang butstrap yang sebenarnya ingin ditutup oleh ciri ini.

Kendalikan kumpulan pelbagai pelayan

Jana kelompok beralamatkan kandungan yang sama ke setiap pelayan API dan lancarkan satu tika pada satu masa. Bandingkan label cincangan konfigurasi dan metrik keputusan kemasukan. Ketidakpadanan cincangan ialah hanyutan, bukan perbezaan versi yang tidak berbahaya; hentikan pelancaran dan pulihkan kelompok yang diketahui sebelum mengubah semantik dasar.

Kekalkan laluan kecemasan (escape hatch)

Dasar statik tidak boleh bergantung pada Service, paramKind atau objek API yang lain. Rujukan tersebut tidak tersedia sebelum keadaan kluster wujud. Simpan laluan peringkat hos yang diaudit untuk menggantikan fail, dan uji bahawa dasar yang salah bentuk atau terlalu luas boleh dikembalikan tanpa panggilan API.

Contoh jawapan berkualiti tinggi

"Saya akan menganggap direktori statik sebagai punca kepercayaan (root-of-trust), mengedarkan kelompok berversi yang ditandatangani ke setiap pelayan API, dan menggunakan dasar statik untuk menolak pengubahsuaian pada sumber kemasukan yang berlabel. Nama yang berakhir dengan .static.k8s.io menjadikan asal-usulnya jelas kelihatan. Pengeditan masa larian disahkan dan ditukar secara atomik; permulaan menolak sebarang kelompok yang tidak sah. Setiap pelayan mengeksport cincangan konfigurasi, jadi pelancaran terhenti jika terdapat hanyutan. Pemulihan ialah perubahan hos yang diaudit, bukan permintaan API, dan ujian kenari merangkumi butstrap, percubaan pemadaman, kemas kini salah bentuk, mula semula pelayan dan kelompok bercampur."

Kesilapan lazim

Melindungi dasar dengan dasar API yang lain → API tidak boleh menjaga konfigurasinya sendiri → sandarkan perlindungan dalam fail statik.
Membiarkan satu pengeditan buruk menggantikan set aktif → Ralat sintaks boleh mengalih keluar semua perlindungan → sahkan keseluruhan set dan kekalkan versi baik yang terakhir.
Bermula dengan manifes yang tidak sah → Pelayan berjalan tanpa garis dasar yang dimaksudkan → gagal pantas sebelum melayani permintaan.
Menganggap pelayan API berkongsi fail → Satu tika boleh menguatkuasakan dasar yang berbeza → edarkan kelompok dan bandingkan cincangan.
Mengalih keluar setiap laluan kecemasan pengendali → Pepijat dasar menjadi gangguan perkhidmatan (outage) → kekalkan laluan pemulihan hos yang berkeistimewaan dan diaudit.

Rubrik pemarkahan dan semakan kendiri

Nilaikan keselamatan butstrap, pemadanan dasar, kemas kini atomik, ketekalan kumpulan pelayan, pemulihan dan ujian. Jawapan yang kukuh menyatakan sebab konfigurasi statik boleh melindungi sumber yang diuruskan oleh API tanpa kemasukan pekeliling (circular admission), dan di mana reka bentuk sengaja memberi pengendali saluran pemulihan bukan API.

Susulan dan lanjutan

Bagaimana jika pelayan API dimulakan semula semasa pelancaran?

Pastikan kelompok lama kekal tersedia, jadikan pemuatan kemasukan statik yang berjaya sebagai syarat kesediaan (readiness), dan bandingkan cincangan yang dilaporkan sebelum menambahkan semula pelayan ke dalam trafik.

Bolehkah dasar statik merujuk kepada webhook Service?

Tidak. Ciri ini serba lengkap sebelum keadaan kluster wujud; gunakan webhook URL sahaja atau dasar CEL tanpa kebergantungan sumber API, kemudian dokumentasikan pertukaran (trade-off) ketersediaan.

Bagaimanakah anda menguji dasar yang menyekat pemadamannya sendiri?

Cipta objek ujian yang dilindungi, cuba kemas kini dan padam melalui API, sahkan penolakan dan rekod audit, kemudian gantikan kelompok statik melalui laluan pemulihan dan sahkan bahawa objek tersebut boleh diuruskan semula.

Apakah ketakberubahan (invariant) pelancaran?

Setiap pelayan API yang melayani mesti menguatkuasakan cincangan kelompok diluluskan yang sama, dan sekurang-kurangnya satu laluan pemulihan yang diaudit mesti kekal tersedia walaupun apabila API menolak perubahan konfigurasi.