Wawancara Backend: Bagaimana Anda Menggunakan OCI Referrers untuk Image Signature dan SBOM?

Perintah dan Konteks

Platform Anda menyimpan image dalam registry OCI, sementara pipeline rilis harus melampirkan signature, SBOM, dan laporan kerentanan. Rancang layanan penemuan dan verifikasi: jika diberikan repositori dan digest image, kembalikan artefak yang dilampirkan, filter berdasarkan artifactType, dukung registry yang tidak memiliki Referrers API, dan blokir image yang belum diverifikasi sebelum deployment. Targetkan backend atau platform engineer; fokuslah pada protokol registry dan batas layanan alih-alih satu cloud SDK tertentu.

Apa yang Dinilai Pewawancara

Jawaban yang kuat memperlakukan digest image sebagai subject yang tidak dapat diubah (immutable), bukan tag. Jawaban tersebut memahami bahwa subject membuat asosiasi, artifactType menjelaskan tujuan, dan Referrers API mengembalikan OCI Index. Jawaban ini juga mencakup tag fallback lama, paginasi, konsistensi cache, dan fakta bahwa menemukan artefak terpisah dari memverifikasi signature. "Membaca tag image" atau "sebuah SBOM membuktikan kepercayaan" menunjukkan model keamanan yang tidak lengkap.

Klarifikasi yang Perlu Ditanyakan Terlebih Dahulu

1. Apakah inputnya berupa tag atau digest? Jika berupa tag, lakukan resolusi dan kunci digest sebelum verifikasi.
2. Apakah registry yang mengembalikan 404 harus didukung? Jika ya, terapkan tag fallback OCI dan tangani pembaruan konkuren.
3. Apakah hasilnya akan membatasi (gate) deployment? Jika ya, verifikasi signature, identitas penerbit, dan digest di dalam batas kepercayaan (trust boundary).
4. Bisakah daftar asosiasi melebihi satu halaman? Jika ya, teruskan nextToken yang buram (opaque) tanpa menginterpretasikannya.

Kerangka Jawaban 30 Detik

"Saya menyelesaikan tag ke digest terlebih dahulu dan menggunakan digest tersebut sebagai subject untuk setiap asosiasi. Saya memanggil /v2/{name}/referrers/{digest} dan memfilter signature, SBOM, atau laporan berdasarkan jenis artefak. Respons 404 dari registry lama memicu tag fallback turunan digest. Penemuan diikuti oleh verifikasi signature dan penerbit sebelum kebijakan memutuskan apakah deployment diizinkan. API daftar dipaginasi dan di-cache dengan TTL singkat menggunakan kunci yang mencakup digest dan filter."

Pembahasan Mendalam Langkah demi Langkah

OCI 1.1 menggunakan manifes subject untuk mengarah ke manifes yang direferensikan, sementara artifactType menjelaskan artefak yang dilampirkan. Referrers API mengembalikan OCI Index yang deskriptornya mencakup digest, jenis media, dan jenis artefak:

GET /v2/{name}/referrers/{subject-digest}?artifactType={type}

Tolak permintaan verifikasi tanpa digest. Tag adalah penunjuk yang dapat berubah (mutable) dan tidak dapat menjadi kunci utama untuk verifikasi signature. Selesaikan sekali, catat digest yang dihasilkan, dan teruskan digest tersebut melalui penemuan, caching, dan admisi.

Dengan registry yang mendukung API tersebut, respons 200 yang berisi Index kosong berarti tidak ada artefak yang dilampirkan. Dengan implementasi lama yang mengembalikan 404, klien membaca tag fallback yang dibentuk dengan mengganti sha256: dengan sha256-. Klien memelihara tag fallback tersebut, sehingga menambahkan referrer baru adalah kondisi race read-modify-write. Penulis (writers) memerlukan penulisan kondisional, percobaan ulang optimis, atau antrean penulis tunggal; pembaca (readers) tidak boleh memperlakukan fallback sebagai sesuatu yang konsisten secara kuat (strongly consistent).

Proses signature, SBOM, dan laporan pemindaian yang ditemukan dalam tiga tahap: filter berdasarkan artifactType dan kebijakan; ambil manifes dan konten yang direferensikan; verifikasi bahwa signature mencakup digest target, penerbit tepercaya, dan status artefak diizinkan. Panduan Microsoft memisahkan integritas, keaslian, dan pemblokiran sebelum konsumsi, sehingga "signature ditemukan" tidak sama dengan "image tepercaya."

API dapat melakukan paginasi. Pertahankan dan teruskan nextToken yang buram, batasi ukuran halaman, dan sertakan registry, repositori, digest subject, jenis artefak, dan konteks otorisasi dalam kunci cache. Karena digest bersifat immutable, hasil penemuan dapat di-cache secara singkat; pencabutan dan perubahan status tetap memerlukan TTL eksplisit dan kebijakan verifikasi ulang. Pada jalur admisi, cache dapat mempercepat penemuan tetapi tidak boleh melewati verifikasi akhir.

Contoh Jawaban Berkualitas Tinggi

Saya akan menjadikan digest sebagai satu-satunya identitas subject. Klien menyelesaikan tag, memanggil OCI Referrers API, dan menggunakan artifactType untuk memisahkan signature, SBOM, dan laporan pemindaian. Registry yang mendukung akan mengembalikan OCI Index; respons 404 dari registry lama memicu tag fallback turunan digest dengan percobaan ulang untuk pembaruan konkuren. Penemuan saja tidak pernah memberikan izin deployment. Layanan admisi memverifikasi target digest signature, identitas penerbit, dan trust root, lalu menerapkan kebijakan. Endpoint meneruskan token paginasi buram dan melakukan cache berdasarkan digest dan filter, sementara setiap deployment melakukan verifikasi ulang alih-alih memperlakukan entri cache sebagai keputusan kepercayaan.

Kesalahan Umum

• Kesalahan → menggunakan tag sebagai kunci signature → Mengapa ini gagal: tag dapat dialihkan ke target lain → Perbaikan: selesaikan dan kunci digest terlebih dahulu.
• Kesalahan → memperlakukan setiap 404 sebagai "tidak ada artefak terlampir" → Mengapa ini gagal: registry lama mungkin tidak mengimplementasikan Referrers → Perbaikan: baca tag fallback spesifikasi.
• Kesalahan → mengizinkan deployment segera setelah signature ditemukan → Mengapa ini gagal: identitas penerbit, cakupan, dan target digest tetap belum diverifikasi → Perbaikan: pisahkan penemuan dari verifikasi kriptografi.
• Kesalahan → mengurai atau membuat nextToken → Mengapa ini gagal: token adalah kursor server yang buram → Perbaikan: teruskan tanpa perubahan dan batasi ukuran halaman serta waktu tunggu (timeouts).

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan Lanjutan 1: Dua proses build memperbarui tag fallback secara bersamaan. Apa yang Anda lakukan?

Perlakukan Index fallback sebagai transaksi read-modify-write. Gunakan penulisan kondisional registry, percobaan ulang optimis, atau antrean penulis tunggal. Jika terjadi konflik, baca Index terbaru dan gabungkan deskriptor baru; jangan pernah menimpa asosiasi build lainnya.

Pertanyaan Lanjutan 2: Signature ada, tetapi SBOM mereferensikan digest yang lebih lama. Apa yang terjadi?

Periksa konsistensi terhadap digest subject saat ini. Signature, SBOM, dan laporan masing-masing harus mereferensikan digest yang sama. Tandai referensi yang lebih lama sebagai tidak berlaku dan blokir admisi; mencocokkan tag image saja tidak aman.

Pertanyaan Lanjutan 3: Registry mengembalikan ribuan referrer. Bagaimana Anda melindungi layanan?

Batasi maxResults, teruskan token buram, dan gunakan cache ber-TTL pendek yang berkunci digest dan jenis artefak. Kueri hanya jenis yang diwajibkan oleh kebijakan pada jalur admisi. Pengindeksan latar belakang dapat menghangatkan hasil, tetapi deployment tetap memverifikasi digest manifes yang dikembalikan dan status kepercayaannya.