Wawancara system design: Bagaimana Anda merancang kebijakan audit Kubernetes dan pipeline log yang andal?

Perintah dan cakupan

Kluster multi-tenant harus dapat menjawab siapa yang mengubah apa, kapan, dan dari mana sambil tetap mengendalikan memori server API, biaya pencatatan log, dan kebocoran Secret. Rancang kebijakan audit, backend file atau webhook, pengambilan sampel dan peringatan, penanganan kegagalan, serta verifikasi forensik.

Hal yang diuji oleh pewawancara

Pemahaman tentang aturan yang berurutan dan perbedaan antara None, Metadata, Request, dan RequestResponse.
Membedakan stage RequestReceived, ResponseStarted, dan ResponseComplete.
Menangani permintaan jangka panjang (long-lived requests), isi payload yang sensitif, pemblokiran backend, dan integritas log.
Menghubungkan tujuan audit dengan peringatan, retensi, kontrol akses, dan latihan simulasi.

Pertanyaan klarifikasi

Sumber daya, verb, tenant, dan prinsipal berisiko tinggi mana yang harus diaudit?
Isi payload mana yang berisi Secret, token, atau data pribadi, dan berapa lama data tersebut harus disimpan?
Apakah backend harus berupa file, webhook, atau keduanya, dan jendela kehilangan data serta latensi apa yang dapat diterima?
Apakah bukti anti-perusakan (tamper evidence), replikasi lintas-wilayah, dan pembatasan akses log mentah diperlukan?

Jawaban 30 detik

Petakan pertanyaan investigasi ke bidang data dan API berisiko tinggi, lalu urutkan aturan dari yang spesifik ke yang umum (catch-all). Gunakan Metadata untuk sebagian besar lalu lintas, Request untuk perubahan terpilih, dan RequestResponse secukupnya agar nilai Secret tidak masuk ke dalam log biasa. Abaikan stage awal hanya jika alasannya eksplisit. Lindungi backend file atau webhook TLS dengan buffering, pembatasan laju (rate limits), enkripsi, pemeriksaan integritas, audit akses, dan peringatan kehilangan data. Lakukan simulasi kegagalan backend untuk membuktikan semantik yang dipilih.

Desain langkah demi langkah

1. Tentukan pertanyaan forensik

Ubah siapa, kapan, di mana, dan apa menjadi bidang data dan kueri. Objek berisiko tinggi mencakup Secret, RoleBinding, webhook, node, dan kuota tenant; pemeriksaan kesehatan rutin jarang membutuhkan payload lengkap. Kebijakan harus menjawab kebutuhan investigasi, bukan mengumpulkan setiap bidang yang memungkinkan.

2. Tulis aturan yang berurutan

Urutkan aturan dari yang spesifik ke yang umum; kecocokan pertama menentukan levelnya. Gunakan Request atau RequestResponse yang diperlukan untuk perubahan berisiko tinggi, Metadata untuk pembacaan rutin, None untuk derau eksplisit, dan fallback tingkat rendah untuk menghindari celah 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. Kontrol stage dan bidang sensitif

Permintaan jangka panjang dapat memancarkan ResponseStarted dan kemudian ResponseComplete; penghilangan stage dapat mengurangi duplikasi, tetapi satu permintaan tidak harus selalu menghasilkan satu event saja. Untuk Secret dan materi identitas, prioritaskan metadata, hash, atau ringkasan terkontrol, jangan pernah menyertakan nilai mentah dalam sistem log normal.

4. Pilih dan lindungi backend

Lakukan rotasi, kompresi, enkripsi, dan penerusan log file secara andal. Webhook membutuhkan TLS, autentikasi, antrean, dan backpressure. Partisi pipeline berdasarkan tenant dan risiko, gunakan penyimpanan append-only, dan lampirkan ID audit, versi kebijakan, serta waktu terima. Konsumen downstream tidak boleh memblokir server API secara sinkron.

5. Tentukan semantik kegagalan

Tentukan apa yang terjadi saat backend tidak dapat dijangkau, disk penuh, antrean meluap, atau terjadi partisi jaringan: drop, blokir, atau turunkan performa (degrade). Operasi tulis berisiko tinggi dapat menggunakan fail-closed hanya setelah mengukur dampaknya terhadap control plane; lalu lintas biasa dapat menggunakan buffering terbatas dan peringatan. Catat penghitung kehilangan data dan rentang pemindaian pemulihan.

6. Verifikasi dan tingkatkan terus-menerus

Hasilkan event dari pengguna yang diketahui, ServiceAccount, proxy, dan permintaan jangka panjang. Periksa kecocokan aturan, stage, atribusi tenant, dan penyuntingan (redaction). Injeksikan penundaan webhook, disk penuh, dan pembaruan kebijakan, lalu verifikasi peringatan, pemulihan, dan kueri forensik. Lacak volume event, kehilangan data, latensi, biaya, dan cakupan investigasi.

Contoh jawaban berkualitas tinggi

Saya akan memetakan pertanyaan investigasi ke bidang data dan sumber daya berisiko tinggi, lalu mengurutkan aturan dari yang spesifik ke yang umum. Lalu lintas rutin mendapatkan Metadata, Secret mendapatkan metadata terkontrol, dan perubahan terpilih mendapatkan Request; stage jangka panjang dibuat eksplisit. Backend menggunakan file terenkripsi atau webhook TLS dengan buffering, backpressure, integritas append-only, dan audit akses, tanpa membiarkan konsumen memblokir server API. Perilaku saat gagal mencakup buffering terbatas, penghitung kehilangan data, dan peringatan, dengan fail-closed dicadangkan untuk operasi tulis berisiko tinggi yang telah diperhitungkan. Event sintetis, permintaan jangka panjang, dan simulasi kegagalan membuktikan kebijakan serta jalur pemulihan.

Kesalahan umum

Mencatat setiap permintaan pada RequestResponse → kebocoran data sensitif dan biaya melonjak → buat tingkatan berdasarkan risiko.
Mengurutkan aturan secara asal-asalan → aturan catch-all menyembunyikan event berisiko tinggi → gunakan urutan dari khusus ke umum.
Hanya memeriksa keberadaan file log → pemblokiran backend atau kehilangan data tidak terlihat → pantau antrean, latensi, dan kehilangan data.
Mengabaikan stage → investigasi jangka panjang kehilangan informasi waktu → tentukan stage dan alasan penghilangan.
Memblokir server API secara sinkron pada konsumen webhook → kelumpuhan control plane → isolasi dengan buffer, batas waktu (timeouts), dan backpressure.

Pertanyaan lanjutan dan tanggapan

Mengapa tidak mencatat setiap permintaan Secret pada tingkat RequestResponse?

Isi payload dapat berisi Secret dalam bentuk teks biasa. Sebagian besar investigasi hanya membutuhkan prinsipal, objek, verb, dan hasil; akses yang lebih dalam memerlukan penyuntingan (redaction), izin terisolasi, dan retensi terkontrol jangka pendek.

Apakah permintaan API harus diblokir ketika webhook tidak tersedia?

Itu tergantung pada tujuan risiko dan ketersediaan. Setelah mengukur dampaknya, operasi tulis berisiko tinggi dapat menggunakan metode fail-closed sementara lalu lintas biasa menggunakan buffering terbatas dan peringatan. Pilihan mana pun harus memperlihatkan cakupan kehilangan data dan pemulihan.

Bagaimana Anda membuktikan bahwa sumber daya yang tidak dikenal tidak diabaikan secara diam-diam?

Pertahankan fallback tingkat rendah, bandingkan inventaris penemuan dengan permintaan sintetis dan versi kebijakan, serta picu peninjauan saat API baru muncul alih-alih mengandalkan deteksi manual.

Wawancara system design: Bagaimana Anda merancang kebijakan audit Kubernetes dan pipeline log yang andal?

Pertanyaan