Petunjuk dan cakupan
Ini adalah pertanyaan system design untuk platform security engineer. Kubernetes v1.36 memperkenalkan kontrol admisi berbasis manifes sebagai fitur alfa. Kebijakan dimuat dari direktori lokal API-server sebelum permintaan dilayani, sehingga desain harus berfungsi sebelum etcd tersedia dan harus menyertakan jalur pemulihan berbasis file.
Yang dievaluasi oleh pewawancara
- Pemisahan antara kebijakan bootstrap dan kebijakan yang dikelola API.
- Validasi atomik, rollback, dan perilaku startup fail-fast.
- Perlindungan konfigurasi kebijakan dan webhook dari penghapusan dengan hak istimewa (privileged).
- Distribusi konfigurasi dan deteksi drift di seluruh instans API-server.
- Escape hatch untuk operator, auditabilitas, dan pengujian mode kegagalan.
Sumber daya mana yang dilindungi?
Klarifikasi apakah baseline hanya melindungi objek ValidatingAdmissionPolicy atau juga binding, webhook, dan konfigurasi mutating. Aturan pencocokan dan blast radius akan berubah bergantung pada jawaban tersebut.
Apa otoritas pemulihannya?
Jika API tidak tersedia atau kebijakan memblokir perbaikannya sendiri, jalur yang berwenang haruslah host API-server atau pipeline konfigurasinya yang immutable. Tentukan siapa yang dapat mengubah jalur tersebut dan bagaimana perubahan ditinjau.
Berapa banyak API server yang berjalan?
Setiap instans membaca filenya sendiri. Sebuah armada (fleet) memerlukan artefak yang dialamatkan berdasarkan konten (content-addressed), pengurutan rollout, dan metrik hash konfigurasi; satu server dapat menggunakan watcher lokal yang lebih sederhana tetapi tetap memerlukan penggantian atomik.
Kerangka jawaban 30 detik
"Saya akan memasang kebijakan manifes kecil yang telah ditinjau sebelum mengaktifkan kebijakan apa pun yang dikelola API. Kebijakan ini menolak pembaruan atau penghapusan untuk sumber daya yang ditandai sebagai dilindungi, dan namanya menggunakan akhiran khusus .static.k8s.io. Setiap API server menerima direktori berversi yang sama dan mengekspos hash konfigurasinya. Perubahan file divalidasi dan ditukar secara atomik; pembaruan yang tidak valid mempertahankan versi baik terakhir, sementara startup yang tidak valid akan langsung fail-fast. Operator memulihkan melalui jalur konfigurasi host, bukan melalui API yang terblokir."
Desain langkah demi langkah
Bootstrap trust boundary
Aktifkan ManifestBasedAdmissionControlConfig di setiap API server dan konfigurasikan staticManifestsDir melalui file konfigurasi admisi yang ada. Simpan manifes dalam artefak read-only yang telah diperiksa integritasnya. Wajibkan setiap nama objek statis diakhiri dengan .static.k8s.io agar metrik dan catatan audit dapat membedakan objek yang didukung file dari objek API.
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
configuration:
staticManifestsDir: /etc/kubernetes/admission/staticTulis aturan perlindungan
Kebijakan bootstrap mencocokkan operasi UPDATE dan DELETE pada kebijakan admisi, binding, dan konfigurasi webhook. Kebijakan ini hanya menolak perubahan jika objek lama memiliki label perlindungan seperti platform.example.com/protected=true. Ini memungkinkan eksperimen biasa tetap berjalan sambil tetap melindungi baseline.
Buat pembaruan bersifat transaksional
API server memvalidasi kumpulan file yang diubah dan menukarnya secara atomik. Jika validasi gagal saat runtime, pertahankan konfigurasi baik sebelumnya dan catat log kesalahan tersebut. Saat startup, buat proses gagal sebelum melayani permintaan jika ada manifes yang tidak valid; memulai secara diam-diam tanpa baseline akan menciptakan celah bootstrap yang sebenarnya ingin ditutup oleh fitur ini.
Mengoperasikan armada multi-server
Render bundel beralamat konten yang sama ke setiap API server dan luncurkan satu instans pada satu waktu. Bandingkan label hash konfigurasi dan metrik keputusan admisi. Ketidakcocokan hash adalah drift, bukan perbedaan versi yang tidak berbahaya; hentikan rollout dan pulihkan bundel yang dikenal sebelum mengubah semantik kebijakan.
Pertahankan escape hatch
Kebijakan statis tidak boleh bergantung pada Service, paramKind, atau objek API lainnya. Referensi tersebut tidak tersedia sebelum status kluster ada. Pertahankan jalur tingkat host yang diaudit untuk mengganti file, dan uji bahwa kebijakan yang salah format atau terlalu luas dapat dikembalikan tanpa panggilan API.
Contoh jawaban berkualitas tinggi
"Saya akan memperlakukan direktori statis sebagai root-of-trust, mendistribusikan bundel berversi yang ditandatangani ke setiap API server, dan menggunakan kebijakan statis untuk menolak modifikasi pada sumber daya admisi yang diberi label. Nama yang berakhiran .static.k8s.io membuat asal-usulnya terlihat jelas. Pengeditan saat runtime divalidasi dan ditukar secara atomik; startup menolak bundel apa pun yang tidak valid. Setiap server mengekspor hash konfigurasi, sehingga rollout berhenti jika terjadi drift. Pemulihan dilakukan melalui perubahan host yang diaudit, bukan permintaan API, dan pengujian canary mencakup bootstrap, upaya penghapusan, pembaruan salah format, restart server, dan bundel campuran."
Kesalahan umum
- Melindungi kebijakan dengan kebijakan API lain → API tidak dapat menjaga konfigurasinya sendiri → jangkar perlindungan dalam file statis.
- Membiarkan satu pengeditan buruk menggantikan kumpulan yang aktif → Kesalahan sintaksis dapat menghapus semua perlindungan → validasi seluruh kumpulan dan pertahankan versi baik terakhir.
- Memulai dengan manifes yang tidak valid → Server berjalan tanpa baseline yang dimaksudkan → fail-fast sebelum melayani permintaan.
- Mengasumsikan API server berbagi file → Satu instans dapat memberlakukan kebijakan yang berbeda → distribusikan bundel dan bandingkan hash.
- Menghapus semua escape hatch operator → Bug kebijakan menjadi pemadaman (outage) → pertahankan jalur pemulihan host yang memiliki hak istimewa dan diaudit.
Rubrik penilaian dan pemeriksaan mandiri
Beri nilai pada keamanan bootstrap, pencocokan kebijakan, pembaruan atomik, konsistensi armada, pemulihan, dan pengujian. Jawaban yang kuat menyatakan mengapa konfigurasi statis dapat melindungi sumber daya yang dikelola API tanpa admisi sirkular, dan di mana desain secara sengaja memberikan saluran pemulihan non-API kepada operator.
Tindak lanjut dan ekstensi
Bagaimana jika API server me-restart selama rollout?
Biarkan bundel lama tetap tersedia, jadikan pemuatan admisi statis yang berhasil sebagai syarat kesiapan (readiness), dan bandingkan hash yang dilaporkan sebelum menambahkan kembali server ke lalu lintas traffic.
Bisakah kebijakan statis mereferensikan webhook Service?
Tidak. Fitur ini berdiri sendiri sebelum status kluster ada; gunakan webhook khusus URL atau kebijakan CEL tanpa dependensi sumber daya API, lalu dokumentasikan kompromi ketersediaannya.
Bagaimana cara menguji kebijakan yang memblokir penghapusannya sendiri?
Buat objek uji yang dilindungi, coba lakukan pembaruan dan penghapusan melalui API, verifikasi penolakan dan catatan audit, lalu ganti bundel statis melalui jalur pemulihan dan konfirmasikan bahwa objek tersebut menjadi dapat dikelola kembali.
Apa invarian rollout-nya?
Setiap API server yang melayani harus memberlakukan hash bundel yang disetujui yang sama, dan setidaknya satu jalur pemulihan yang diaudit harus tetap tersedia bahkan ketika API menolak perubahan konfigurasi.