Wawancara Backend: Bagaimana Anda Mengatur Propagasi W3C Baggage Secara Aman?

Pertanyaan dan skenario

Beberapa microservice menggunakan header W3C baggage untuk konteks tenant, eksperimen, dan sumber permintaan. Beberapa service melintasi batas perusahaan atau domain data, sehingga korelasi OpenTelemetry harus tetap terjaga sementara data pribadi dan pengidentifikasi internal tidak boleh masuk ke sistem downstream yang tidak tepercaya.

Apa yang sedang diuji oleh pewawancara

• Memisahkan Baggage dari Trace Context dan mengenali propagasi key-value yang arbitrer.
• Menerapkan allowlist batas kepercayaan, batas ukuran, redaksi, dan penghapusan alih-alih penerusan secara membabi buta.
• Menyeimbangkan observabilitas, kompatibilitas, graceful degradation, dan bukti audit.

Pertanyaan klarifikasi sebelum menjawab

Klarifikasi service mana saja yang berbagi trust domain, katalog field yang diizinkan, ukuran header maksimum, titik masuk browser atau antrean (queue), retensi telemetri, dan apakah sistem downstream menyimpan (persist) Baggage. Klarifikasi apakah tujuannya adalah memblokir key sensitif, membatasi propagasi lintas-domain, atau memigrasikan custom header.

Kerangka jawaban 30 detik

Saya akan memperlakukan Baggage sebagai input yang tidak tepercaya. Parsing dan normalisasikan pada saat ingress, lalu pertahankan, ubah nama, hash, atau hapus field berdasarkan sumber, trust domain tujuan, dan kebijakan. Gateway membatasi ukuran key/value dan ukuran total, tidak pernah menyalin nilai mentah ke dalam log atau respons pengguna, serta menggunakan allowlist ditambah versi kebijakan pada saat egress lintas-domain. Traceparent ditangani secara terpisah. Jika pemfilteran gagal, hapus field opsional, lanjutkan permintaan inti, dan catat tindakan kebijakan yang dapat diaudit.

Jawaban mendalam langkah demi langkah

1. Kelola katalog field berversi: tujuan, kelas data, domain sumber dan tujuan yang diizinkan, panjang maksimum, dan izin logging.
2. Parsing format standar pada saat ingress dan tolak key yang tidak valid, karakter kontrol, nilai yang melebihi ukuran, dan konflik duplikat. Simpan digest permintaan, bukan header sensitifnya.
3. Propagasikan allowlist di dalam satu trust domain. Di seluruh domain yang berbeda, kirimkan hanya public key yang diminimalkan, atau alias tenant yang tidak dapat dibalik (irreversible) atau referensi bertanda tangan berumur pendek.
4. Tambahkan pemfilteran eksplisit pada titik injeksi OpenTelemetry agar instrumentasi otomatis tidak menyalin setiap item Baggage ke dalam span, log, atau atribut metrik.
5. Batasi total byte, jumlah item, dan jumlah hop. Jika terjadi overflow, hapus field berprioritas rendah dan keluarkan event kebijakan internal tanpa menampilkan ulang (echoing) data sensitif.
6. Evaluasi ulang kebijakan pada setiap egress; gunakan kembali katalog untuk antrean dan pekerjaan asinkron. Jangan pernah menggunakan Baggage sebagai kredensial otorisasi.
7. Audit nama field, versi kebijakan, tindakan, dan tujuan, bukan nilai aslinya. Uji kebocoran sintetis, serangan ukuran, dan akumulasi multi-hop.

incoming baggage: tenant=acme,experiment=A,pii_email=alice@example.org
same-trust output: tenant=acme,experiment=A
cross-trust output: tenant_ref=hash:v3:...,experiment=A

Contoh jawaban berkualitas tinggi

Pertama-tama saya akan menyatakan bahwa Baggage bukan merupakan pembawa autentikasi atau otorisasi; setiap nilainya tidak tepercaya. Katalog field berversi mengarahkan parsing dan batas pada ingress, dan allowlist mengatur propagasi dalam domain yang sama. Di seluruh batas kepercayaan, kirimkan hanya alias yang diminimalkan atau referensi berumur pendek. Tangani trace context OpenTelemetry secara terpisah, filter injeksi otomatis, dan jangan pernah mencatat nilai mentah ke log. Jika terjadi overflow atau kebijakan tidak dikenal, hapus field opsional, lanjutkan permintaan inti, dan catat nama field, tindakan, serta versi kebijakan. Pengujian sintetis multi-hop, pengujian batas antrean, dan kueri audit memverifikasi bahwa risiko privasi dikurangi tanpa menyembunyikannya di balik trace yang sehat.

Kesalahan umum

• Memperlakukan Baggage sebagai identitas tepercaya, otorisasi, atau isolasi tenant.
• Mengizinkan key arbitrer melintasi batas kepercayaan atau hanya mengandalkan blacklist string.
• Menuliskan header lengkap ke dalam log, trace, atau respons error.
• Mengatur HTTP tetapi melupakan antrean, percobaan ulang (retry), dan pekerjaan asinkron.
• Mengembalikan kode 4xx untuk overflow opsional, atau menghapus data secara diam-diam tanpa event audit.

Pertanyaan lanjutan dan tanggapan

Apa perbedaan antara Baggage dan Trace Context?

Trace Context membawa metadata standar yang diperlukan untuk tracing terdistribusi. Baggage adalah kumpulan key-value yang ditentukan oleh aplikasi dan dapat bekerja secara independen, sehingga semantik dan risiko privasinya menjadi tanggung jawab aplikasi.

Mengapa lebih memilih allowlist daripada blacklist?

Key pada Baggage tidak memiliki semantik bisnis yang tetap dan field baru akan terus muncul seiring waktu. Allowlist menolak data yang tidak dikenal secara default, mencegah service atau vendor baru menyebarkan nilai sensitif secara tidak sengaja.

Haruskah kegagalan pemfilteran memblokir permintaan?

Jika field tersebut hanya bersifat observasional, hapus dan lanjutkan. Jika alur bisnis membutuhkannya, kembalikan error kebijakan yang dapat dikenali tanpa menampilkan nilainya kembali. Katalog harus menandai field mana yang bersifat kritis.

Bagaimana Anda membuktikan bahwa nilai mentah tidak masuk ke dalam telemetri?

Jalankan pengujian redaksi baik di Collector maupun SDK, pindai log, atribut span, dan label metrik, catat nama dan versi kebijakan alih-alih nilainya, serta pasang peringatan (alert) pada synthetic canary.