Topik wawancara representatif

Wawancara umum: Bagaimana Anda mengevaluasi pengemasan OpenTelemetry satu perintah untuk Linux secara aman?

UmumSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Sebuah tim ingin menggunakan repositori pengemasan Linux OpenTelemetry untuk pemantauan host yang cepat. Repositori tersebut masih tahap awal dan paket-paketnya belum ditandatangani. Rancang evaluasi yang aman dan rencana canary.

Prompt dan cakupan

Sebuah armada Linux multi-distribusi ingin menginstal OpenTelemetry Injector, paket auto-instrumentation, dan Collector dari repositori pengemasan untuk mengurangi penerapan manual. Proyek tersebut menyatakan bahwa upaya pengemasan masih tahap awal, repositori tersebut bukan hosting tingkat produksi, dan paket-paketnya belum ditandatangani. Rancang batasan keamanan, validasi, izin, dan rollback dari eksperimen hingga ke produksi.

Apa yang sedang diuji oleh pewawancara

Pewawancara sedang menguji apakah Anda memisahkan kenyamanan instalasi dari kepercayaan supply chain, dan apakah Anda mengidentifikasi izin skrip, asal-usul (provenance) paket, efek samping auto-instrumentation, egress jaringan, dan rollback versi. Jawaban yang kuat menyatakan lingkungan mana yang boleh mencobanya, mana yang harus menunggu, serta bukti dan guardrail apa yang diperlukan.

Pertanyaan untuk diklarifikasi terlebih dahulu

  • Distribusi, arsitektur, proxy, dan kebijakan peningkatan (upgrade) apa yang berjalan pada host target?
  • Apakah Anda menginstal Collector, Injector, paket bahasa, atau semua komponen?
  • Apakah host diizinkan menambahkan layanan systemd, hak istimewa eBPF, dan endpoint outbound?
  • Apa persyaratan penandatanganan, proxy artefak, SBOM, dan rollback yang dimiliki organisasi?

Jawaban 30 detik

“Saya tidak akan menjalankan skrip satu perintah dari repositori tahap awal secara langsung di produksi. Pada host yang terisolasi, saya akan memeriksa konten paket, asal-usul, hash, izin, unit systemd, egress jaringan, dan jalur uninstal. Paket yang tidak ditandatangani dapat menjadi eksperimen jangka pendek tetapi tidak dapat melewati gerbang supply chain. Kandidat produksi memerlukan mirror internal, verifikasi tanda tangan, least privilege, dan rollback berversi. Lakukan canary pada host non-kritis terlebih dahulu, dengan memantau CPU, memori, jaringan, startup proses, kebocoran data, dan keberhasilan uninstal; hentikan ekspansi jika ada guardrail yang gagal.”

Solusi langkah demi langkah

1. Tentukan batasan uji coba

Beri label repositori resmi sebagai sumber eksperimental, bukan persetujuan produksi. Pilih host yang dapat dibangun kembali tanpa data sensitif, dan jangan pernah menjalankannya langsung pada database inti, bastion, atau node kontrol berhak istimewa tinggi.

2. Verifikasi supply chain

Kunci commit repositori, versi paket, dan dependensi. Validasi URL unduhan, hash, asal-usul build, SBOM, dan status tanda tangan. Paket yang tidak ditandatangani memerlukan tinjauan internal dan proxy yang terisolasi; jangan mengatasi kegagalan instalasi dengan menggunakan trusted milik skrip atau opsi lewati verifikasi.

3. Periksa hak istimewa dan efek samping

Tinjau skrip instalasi, unit systemd, jalur file, identitas, kapabilitas, persyaratan eBPF, dan perubahan firewall. Pastikan Injector hanya menargetkan proses yang disetujui, Collector hanya membaca log dan metrik yang diperlukan, serta kredensial berupa referensi berumur pendek dan bukan file teks biasa.

4. Kontrol egress data

Buat daftar endpoint OTLP, TLS, proxy, percobaan ulang (retries), antrean, dan aturan redaksi. Kirim data ke backend yang terisolasi terlebih dahulu dan verifikasi bahwa nama layanan, pengidentifikasi host, argumen command-line, dan data pribadi tidak melintasi batas tenant atau wilayah. Tentukan perilaku drop atau buffer lokal yang eksplisit saat jaringan tidak tersedia.

5. Rancang metrik canary

Luncurkan berdasarkan distribusi, arsitektur, dan kekritisan bisnis. Amati keberhasilan instalasi, startup proses, CPU dan memori, error eBPF, antrean Collector, egress, kecocokan bidang sensitif, dan keberhasilan uninstal. Hentikan penambahan host baru saat guardrail gagal; jangan memperluas hak istimewa untuk menyembunyikan masalah tersebut.

6. Rollback dan peningkatan

Simpan paket asli, konfigurasi, status systemd, dan manifes file. Lakukan rollback dengan menghentikan Injector dan Collector, lalu memulihkan paket lama dan status firewall. Catat perintah uninstal yang dapat diulang dan waktu pemulihan per versi. Pertahankan uji coba tetap terbatas sampai penandatanganan, artefak yang di-host, dan tinjauan keamanan matang.

Jawaban model

Saya akan memperlakukan repositori ini sebagai eksperimental. Pada host yang dapat dibangun kembali, verifikasi commit, hash, SBOM, tanda tangan, dependensi, systemd, izin, eBPF, dan egress; paket yang tidak ditandatangani tidak boleh masuk ke produksi. Batasi target Injector, gunakan akses Collector dengan least privilege, kredensial berumur pendek, TLS, redaksi, dan backend yang terisolasi. Lakukan canary berdasarkan distribusi dan kekritisan bisnis sambil memantau metrik instalasi, sumber daya, antrean, egress, dan uninstal. Pertahankan paket lama, konfigurasi, dan langkah-langkah pemulihan; hentikan host baru dan lakukan rollback secara individual jika terjadi kegagalan. Lakukan ekspansi hanya setelah mirror internal dan proses penandatanganan matang.

Kesalahan umum

  • Menjalankan skrip satu perintah di produksi → izin dan asal-usul tidak diketahui → isolasi, tinjau, dan buat mirror internal terlebih dahulu.
  • Mengabaikan paket yang tidak ditandatangani → asal-usul tidak dapat dibuktikan → wajibkan hash, SBOM, dan gerbang tanda tangan.
  • Membiarkan Injector menargetkan setiap proses → risiko bisnis dan privasi meluas → gunakan allowlist proses.
  • Hanya memantau instalasi → data runtime dapat bocor → pantau egress, redaksi, dan metrik sumber daya.
  • Tidak menyimpan manifes uninstal atau pemulihan → kegagalan berubah menjadi forensik manual → gunakan langkah-langkah rollback berversi.

Pertanyaan lanjutan dan tanggapan

Apakah paket yang tidak ditandatangani sama sekali tidak dapat diuji?

Paket tersebut dapat diuji secara singkat pada host yang terisolasi dan sekali pakai tanpa data sensitif, dengan diberi label yang jelas sebagai eksperimental. Hasil pengujian tidak dapat dianggap sebagai persetujuan produksi.

Mengapa tidak langsung memberikan akses root pada skrip?

Root memperluas radius dampak (blast radius) dari skrip dan dependensi. Tinjau izin yang diperlukan terlebih dahulu, lalu gunakan akun khusus, kapabilitas, dan layanan systemd yang terkontrol.

Bagaimana Anda membuktikan bahwa auto-instrumentation tidak mengubah fungsionalitas bisnis?

Bandingkan host dengan versi yang sama untuk melihat error, latensi, argumen startup, dan critical path. Periksa span baru, log, dan koneksi jaringan; nonaktifkan Injector jika terjadi anomali daripada mengubah kode bisnis.

Kapan ini dapat masuk ke produksi?

Wajibkan mirror artefak yang terkontrol, tanda tangan yang dapat diverifikasi, SBOM, least privilege, audit egress, rollback yang dapat diulang, dan penerimaan bertahap. Jangan menyimpulkan kesiapan produksi hanya dari ketersediaan repositori tahap awal.

Sumber publik

Pertanyaan terkait