Temu duga reka bentuk sistem: Bagaimanakah anda mereka bentuk dasar audit Kubernetes dan saluran paip log yang boleh dipercayai?

Gesaan dan skop

Kluster berbilang penyewa mesti dapat menjawab siapa yang mengubah apa, bila, dan dari mana sambil mengawal memori pelayan API, kos pengelogan, dan kebocoran Secret. Reka bentuk dasar audit, bahagian belakang fail atau webhook, pensampelan dan amaran, pengendalian kegagalan, serta pengesahan forensik.

Perkara yang diuji oleh penemu duga

Memahami peraturan yang disusun dan perbezaan antara None, Metadata, Request, dan RequestResponse.
Membezakan peringkat RequestReceived, ResponseStarted, dan ResponseComplete.
Mengendalikan permintaan jangka panjang (long-lived requests), jasad sensitif, sekatan bahagian belakang, dan integriti log.
Menghubungkan matlamat audit dengan amaran, pengekalan, kawalan akses, dan latihan simulasi.

Soalan penjelasan

Sumber berisiko tinggi, kata kerja, penyewa, dan prinsipal manakah yang mesti diaudit?
Jasad manakah yang mengandungi Secret, token, atau data peribadi, dan berapa lama ia mesti dikekalkan?
Patutkah bahagian belakang berupa fail, webhook, atau kedua-duanya, dan apakah tetingkap kehilangan data dan kependaman yang boleh diterima?
Adakah bukti usikan (tamper evidence), replikasi rentas rantau, dan akses log mentah yang terhad diperlukan?

Jawapan 30 saat

Petakan soalan siasatan kepada medan dan API berisiko tinggi, kemudian susun peraturan daripada khusus kepada umum (catch-all). Gunakan Metadata untuk kebanyakan trafik, Request untuk perubahan terpilih, dan RequestResponse secara berhati-hati supaya nilai Secret tidak memasuki log biasa. Gugurkan peringkat awal hanya apabila alasannya jelas. Lindungi bahagian belakang fail atau webhook TLS dengan penimbalan, had kadar, penyulitan, semakan integriti, audit akses, dan amaran kehilangan. Lakukan latihan simulasi kegagalan bahagian belakang untuk membuktikan semantik yang dipilih.

Reka bentuk langkah demi langkah

1. Tentukan soalan forensik

Tukarkan siapa, bila, di mana, dan apa kepada medan dan pertanyaan. Objek berisiko tinggi termasuk Secret, RoleBindings, webhook, nod, dan kuota penyewa; pemeriksaan kesihatan rutin jarang memerlukan jasad penuh. Dasar ini harus menjawab siasatan, bukan mengumpul setiap medan yang mungkin.

2. Tulis peraturan yang disusun

Susun peraturan daripada khusus kepada umum; padanan pertama menetapkan tahap. Gunakan Request atau RequestResponse yang diperlukan untuk perubahan berisiko tinggi, Metadata untuk bacaan rutin, None untuk hingar eksplisit, dan sandaran tahap rendah untuk mengelakkan jurang tersembunyi.

yaml

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  - level: Request
    resources:
      - group: ""
        resources: ["secrets"]
  - level: Metadata
    omitStages: ["RequestReceived"]
    resources:
      - group: ""
        resources: ["pods"]
  - level: None
    users: ["system:kube-probe"]

3. Kawal peringkat dan medan sensitif

Permintaan jangka panjang boleh mengeluarkan ResponseStarted dan kemudian ResponseComplete; pengguguran peringkat boleh mengurangkan pertindihan, tetapi satu permintaan tidak semestinya menghasilkan satu peristiwa sahaja. Untuk Secret dan bahan identiti, utamakan metadata, cincangan (hashes), atau ringkasan terkawal, jangan sesekali meletakkan nilai mentah dalam sistem log biasa.

4. Pilih dan lindungi bahagian belakang

Putar, mampatkan, sulitkan, dan majukan log fail dengan andal. Webhook memerlukan TLS, pengesahan, baris gilir, dan tekanan balikan (backpressure). Bahagikan saluran paip mengikut penyewa dan risiko, gunakan storan tambah sahaja (append-only), dan lampirkan ID audit, versi dasar, serta masa penerimaan. Pengguna hiliran tidak boleh menyekat pelayan API secara segerak.

5. Tentukan semantik kegagalan

Tentukan perkara yang berlaku apabila bahagian belakang tidak dapat dihubungi, cakera penuh, baris gilir melimpah, atau pemecahan rangkaian berlaku: gugurkan, sekat, atau turunkan prestasi (degrade). Operasi tulis berisiko tinggi boleh menggunakan fail-closed hanya selepas mengukur kesan satah kawalan; trafik biasa boleh menggunakan penimbalan terhad dan amaran. Catatkan pembilang kehilangan dan julat imbasan pemulihan.

6. Sahkan dan pertingkatkan secara berterusan

Hasilkan peristiwa daripada pengguna yang diketahui, ServiceAccounts, proksi, dan permintaan jangka panjang. Semak padanan peraturan, peringkat, atribusi penyewa, dan penyuntingan (redaction). Suntik kelewatan webhook, cakera penuh, dan kemas kini dasar, kemudian sahkan amaran, pemulihan, dan pertanyaan forensik. Jejaki volum peristiwa, kehilangan, kependaman, kos, dan liputan siasatan.

Model jawapan berkualiti tinggi

Saya akan memetakan soalan siasatan kepada medan dan sumber berisiko tinggi, kemudian menyusun peraturan daripada khusus kepada umum. Trafik rutin mendapat Metadata, Secret mendapat metadata terkawal, dan perubahan terpilih mendapat Request; peringkat jangka panjang dinyatakan secara eksplisit. Bahagian belakang menggunakan fail yang disulitkan atau webhook TLS dengan penimbalan, tekanan balikan, integriti tambah sahaja, dan pengauditan akses, tanpa membiarkan pengguna menyekat pelayan API. Tingkah laku kegagalan merangkumi penimbalan terhad, pembilang kehilangan, dan amaran, dengan fail-closed dikhaskan untuk operasi tulis berisiko tinggi yang diukur. Peristiwa sintetik, permintaan jangka panjang, dan latihan simulasi kegagalan membuktikan dasar dan laluan pemulihan.

Kesilapan lazim

Merekodkan setiap permintaan pada RequestResponse → kebocoran maklumat sensitif dan kos tidak terkawal → bahagikan mengikut tahap risiko.
Menyusun peraturan secara cuai → peraturan umum menyembunyikan peristiwa berisiko tinggi → susun daripada khusus kepada umum.
Hanya menyemak kewujudan fail log → sekatan bahagian belakang atau kehilangan tidak dapat dilihat → pantau baris gilir, kependaman, dan kehilangan.
Mengabaikan peringkat → siasatan jangka panjang kehilangan garis masa → tentukan peringkat dan sebab pengguguran.
Menyekat pelayan API secara segerak pada pengguna webhook → keruntuhan satah kawalan → asingkan dengan penimbal, had masa tamat (timeouts), dan tekanan balikan.

Soalan susulan dan jawapan

Mengapa tidak merekodkan setiap permintaan Secret pada RequestResponse?

Jasad mungkin mengandungi Secret teks biasa. Kebanyakan siasatan memerlukan prinsipal, objek, kata kerja, dan hasil; akses yang lebih mendalam memerlukan penyuntingan, kebenaran terpencil, dan pengekalan terkawal jangka pendek.

Patutkah permintaan API disekat apabila webhook tidak tersedia?

Ia bergantung pada matlamat risiko dan ketersediaan. Selepas mengukur kesannya, operasi tulis berisiko tinggi boleh gagal secara tertutup (fail closed) manakala trafik biasa menggunakan penimbalan terhad dan amaran. Mana-mana pilihan mesti mendedahkan skop kehilangan dan pemulihan.

Bagaimanakah anda membuktikan bahawa sumber yang tidak diketahui tidak digugurkan secara senyap?

Kekalkan sandaran tahap rendah, bandingkan inventori penemuan dengan permintaan sintetik dan versi dasar, serta cetuskan semakan apabila API baharu muncul dan bukannya bergantung pada pengesanan manual.

Temu duga reka bentuk sistem: Bagaimanakah anda mereka bentuk dasar audit Kubernetes dan saluran paip log yang boleh dipercayai?

Soalan