Wawancara system design: Bagaimana Anda merancang identitas workload SPIFFE terfederasi?

Masalah dan konteks

Sebuah perusahaan menjalankan microservice multi-tenant di dua cloud dan satu klaster privat. Tim yang berbeda mengoperasikan setiap lingkungan, dan lingkungan produksi harus tetap terpisah dari staging. Layanan pembayaran memanggil layanan pelaporan, tetapi rahasia API berumur panjang dan peran spesifik-cloud tidak boleh disalin ke dalam image. Rancang identitas workload terfederasi lintas trust domain.

Workload memerlukan identitas yang berumur pendek dan dapat diverifikasi. Penerima hanya boleh memercayai trust domain eksternal, SPIFFE ID, audience, dan tindakan bisnis yang telah disetujui. Cakup penamaan SPIFFE ID, SPIRE Server dan Agent, atestasi node dan workload, X.509-SVID atau JWT-SVID, pengambilan foreign-bundle, pemetaan otorisasi, rotasi, pencabutan, caching, pemulihan bencana, dan migrasi dari kredensial statis.

Pertahankan invarian berikut:

Sumber identitas membuktikan proses terkontrol mana yang sedang berjalan, bukan sekadar bahwa sebuah mesin memiliki alamat jaringan.
Bundle trust domain tidak secara otomatis memberikan otoritas lokal kepada setiap workload eksternal.
Penerima berhenti menerima SVID yang telah kedaluwarsa atau dicabut dalam batas waktu yang ditentukan.
Kunci privat dibuat oleh workload atau pengelola kunci terkontrol; control plane tidak mendistribusikan kunci privat berumur panjang.
Federasi mempertukarkan materi identitas dan trust; layanan sumber daya tetap melakukan otorisasi bisnis.

Apa yang sedang dievaluasi oleh pewawancara

Jawaban yang kuat membedakan batasan antara trust domain, SPIFFE ID, SVID, SPIRE Server, Agent, dan Workload API. SPIFFE mendefinisikan penamaan identitas dan dokumen yang dapat diverifikasi; SPIRE mengimplementasikan atestasi node dan workload serta penerbitan SVID. Identitas bukanlah izin: spiffe://prod.example/ns/payments/sa/worker tetap memerlukan kebijakan izin (allow policy) pada layanan pelaporan.

Sinyal kedua adalah federasi. SPIFFE Federation mempertukarkan materi trust publik melalui endpoint bundle yang dikonfigurasi dan diautentikasi dengan TLS. Penerima harus mengetahui trust domain mana yang diwakili oleh URL tersebut; penerima tidak boleh mengunduh root untuk domain arbitrer dari sebuah permintaan. Workload API dapat mengembalikan foreign bundle, dan pemverifikasi memilih bundle yang cocok dengan trust domain dari SVID.

Sinyal ketiga adalah rantai bukti (proof chain). Atestasi node membuktikan node milik Agent, dan atestasi workload mencocokkan atribut tepercaya dari kernel, kubelet, atau container-runtime terhadap selector registrasi. Namespace, label, atau identitas klien yang dideklarasikan sendiri saja tidak cukup untuk menghadapi kredensial layanan yang dicuri.

Terakhir, bahas aspek operasional: bundle federasi yang kedaluwarsa, rotasi kunci root, Agent yang terputus, cache basi, titik kegagalan tunggal (single point of failure) pada control plane, pergeseran waktu jam (clock skew) lintas cloud, layanan warisan (legacy) yang tidak dapat memuat SVID, dan rollback tanpa menonaktifkan verifikasi.

Pertanyaan klarifikasi di awal

Trust domain mana yang benar-benar memerlukan hubungan saling percaya? Jika pembayaran hanya memanggil pelaporan, jangan membangun grafik trust yang terhubung penuh (fully meshed); tentukan edge satu arah atau minimal.
X.509-SVID atau JWT-SVID? mTLS dan identitas koneksi cocok untuk link layanan berumur panjang; HTTP lintas-cloud atau sumber daya OIDC eksternal mungkin memerlukan audience JWT. Cache validasi dan jendela kebocoran keduanya berbeda.
Siapa yang mengoperasikan endpoint foreign bundle? Satu perusahaan dapat berbagi tata kelola; perusahaan yang berbeda memerlukan materi publik yang eksplisit, identitas TLS, dan pemetaan domain yang ditinjau.
Berapa target pencabutannya? Misalnya, masa pakai SVID maksimum 15 menit, polling bundle 60 detik, dan pemblokiran koneksi baru selama lima menit setelah pencabutan darurat.
Bagaimana workload membuktikan dirinya? Kubernetes ServiceAccount, dokumen instans cloud, TPM, dan token gabung sekali pakai yang terkontrol memiliki asumsi yang berbeda.
Bisakah layanan legacy menggunakan SPIFFE? Jika tidak, dapatkah sidecar atau gateway menerjemahkannya secara terbatas? Identitas dan izinnya memerlukan batasannya sendiri.

Jawaban 30 detik

“Saya akan membuat trust domain independen untuk production, staging, dan on-premise serta menetapkan SPIFFE ID stabil yang tidak memuat rahasia tenant. SPIRE Server di setiap domain mengelola entri registrasi. Sebuah Agent membuktikan nodenya, kemudian menggunakan atribut proses lokal untuk atestasi workload; workload memperoleh X.509-SVID atau JWT-SVID berumur pendek dari Workload API.

Domain pembayaran hanya akan mengonfigurasi endpoint foreign bundle milik domain pelaporan dan mem-pin domain, identitas TLS, serta pemetaan yang diizinkan. Pelaporan memvalidasi tanda tangan, masa kedaluwarsa SVID, audience, dan peer bundle, lalu mengotorisasi SPIFFE ID lengkap, lingkungan, konteks tenant, dan tindakan. Pembaruan bundle dan SVID menggunakan streaming API, TTL pendek, dan metrik versi. Jika control plane tidak tersedia, materi yang sebelumnya telah diverifikasi dalam batas tertentu dapat melayani lalu lintas berisiko rendah, tetapi koneksi baru berisiko tinggi akan fail-closed. Migrasi menjalankan kredensial lama dan SVID secara paralel, melakukan canary berdasarkan kumpulan layanan (service pool), dan menghapus rahasia hanya setelah target audit dan pencabutan terbukti.”

Desain langkah demi langkah

Langkah 1: Partisi trust domain dan beri nama identitas

Trust domain adalah namespace identitas dan batasan root-of-trust. Lingkungan production, staging, PCI, atau organisasi yang diatur secara terpisah harus menggunakan domain terpisah alih-alih satu root global. Contoh ID:

text

spiffe://prod.example/ns/payments/sa/worker
spiffe://reports.partner/ns/analytics/sa/reader

Path harus mengekspresikan prinsipal bisnis dan cakupan tata kelola yang stabil, bukan nama pod, IP, atau hash deployment yang berumur pendek. Versi, tenant, dan region dapat berupa selector, input kebijakan, atau klaim token. Mengodekan setiap deployment ke dalam ID akan mengubah pemeliharaan rotasi dan otorisasi menjadi migrasi armada (fleet migration).

Catat federasi sebagai edge yang eksplisit: prod.example dapat memvalidasi bundle milik reports.partner, tetapi hanya untuk audience reports-api dan tindakan ReportRead. Penerima tidak boleh mengizinkan panggilan hanya karena kedua domain menggunakan SPIFFE.

Langkah 2: Buat Server, Agent, dan entri registrasi

SPIRE Server menyimpan entri registrasi, materi penandatanganan, dan otorisasi node. Sebuah Agent berjalan di setiap node workload dan mengekspos Workload API lokal. Server hanya mengirimkan entri yang boleh dikelola oleh Agent tersebut kepada Agent yang bersangkutan, sehingga membatasi dampak ledakan (blast radius) dari satu kompromi node.

Sebuah entri harus mengikat SPIFFE ID, parent SPIFFE ID, kumpulan selector, profil SVID yang diizinkan, dan audience. Selector berasal dari orchestrator tepercaya atau properti node: namespace Kubernetes, service account, image digest, atau identitas instans cloud. Jangan hanya mengandalkan label yang dapat diedit pengguna atau memperlakukan string konfigurasi arbitrer sebagai bukti atestasi.

Langkah 3: Rancang atestasi dua tahap

Saat startup node, Agent membuktikan identitasnya dengan dokumen instans cloud, Kubernetes ServiceAccount, TPM, atau token gabung sekali pakai. Server memvalidasi bukti tersebut secara independen dan menerbitkan identitas Agent. Workload kemudian memanggil Workload API melalui Unix domain socket atau endpoint terbatas. Agent menggunakan ID proses, fakta kernel, kubelet, atau container-runtime untuk mendapatkan selector, mencocokkan entri registrasi, dan mengembalikan SVID.

Hal ini menjelaskan mengapa Workload API tidak perlu menggunakan autentikasi klien jaringan biasa: Agent mengidentifikasi pemanggil lokal secara out-of-band. Izin socket, isolasi namespace, dan kepercayaan pada kernel host atau kubelet termasuk dalam threat model. Jika Agent tidak dapat mengidentifikasi pemanggil, Agent harus mengembalikan PermissionDenied alih-alih identitas hak istimewa tinggi default.

Langkah 4: Pilih profil SVID dan kelola kunci

X.509-SVID cocok untuk mTLS dan identitas layanan tingkat koneksi. JWT-SVID cocok untuk pertukaran HTTP atau OIDC eksternal di mana audience harus dibawa bersama asersi. Pemverifikasi JWT-SVID harus menggunakan bundle untuk subject trust domain; JWKS arbitrer bukanlah root of trust yang sama.

SVID harus berumur pendek dan di-stream melalui Workload API. Workload atau pengelola kunci Agent membuat kunci privat dan menyimpannya di memori terbatas atau deskriptor file. Server menandatangani kunci publik yang sesuai tetapi tidak pernah menulis kunci privat berumur panjang ke dalam image, variabel lingkungan, atau konfigurasi biasa. Workload dengan banyak identitas dapat menggunakan hint atau pemilihan eksplisit untuk audience internal dan eksternal sehingga default tidak dapat disalahgunakan.

Langkah 5: Buat federasi bundle lintas domain secara aman

Control plane federasi meninjau foreign domain, endpoint bundle, profil endpoint, sertifikat TLS, dan awalan SPIFFE ID yang diizinkan. Klien mengetahui sebelumnya trust domain mana yang diwakili oleh URL tersebut. Autentikasi TLS membuktikan endpoint transport; bundle yang dikembalikan tetap memerlukan pemeriksaan domain, versi, tanda tangan, dan kedaluwarsa.

Simpan foreign bundle di trust store berversi. Selama validasi peer, pilih bundle berdasarkan trust domain milik SVID; tolak jika kecocokan tidak ditemukan. Jangan jadikan foreign bundle sebagai root penerbit lokal, dan jangan mengganti konfigurasi secara permanen karena pengalihan (redirect) sementara. Polling, ETag, kedaluwarsa, dan versi sukses terakhir harus dapat diobservasi.

Langkah 6: Petakan identitas ke otorisasi sumber daya

PEP layanan pelaporan memverifikasi peer mTLS atau JWT-SVID, lalu mengirimkan SPIFFE ID lengkap, trust domain, audience, tenant, dan tindakan ke PDP. Contoh aturannya adalah:

text

allow if trust_domain == "prod.example"
   and spiffe_id == "spiffe://prod.example/ns/payments/sa/worker"
   and audience == "reports-api"
   and action == "ReportRead"
   and tenant == resource.tenant

Keterjangkauan jaringan, SVID yang valid, dan edge federasi bukanlah izin bisnis. Layanan sumber daya tetap memeriksa kepemilikan tenant, akses tingkat baris, persetujuan, dan rate limit. Jika identitas workload harus menjangkau IAM cloud atau layanan OIDC eksternal, gunakan broker terbatas yang terikat pada audience, scope, TTL SVID, dan tujuan; jangan pernah memberikan satu peran cloud yang luas ke setiap workload.

Langkah 7: Koordinasikan rotasi, pencabutan, dan konsistensi cache

Kedaluwarsa SVID ditangani melalui stream Workload API. Klien secara atomik mengganti sertifikat dan kunci serta membiarkan koneksi baru menggunakan materi baru terlebih dahulu. Rotasi trust bundle menggunakan tumpang tindih berbatas (bounded overlap) antara root lama dan baru; hapus root lama hanya setelah pemverifikasi memuat versi baru dan SVID serta koneksi lama telah dikosongkan (drained). Kompromi darurat tidak menggunakan overlap normal; publikasikan versi pencabutan atau penolakan dan perpendek jendela penerimaan.

Cache versi bundle, penerbit, trust domain, masa kedaluwarsa SVID, dan versi kebijakan. Target pencabutan lima menit yang diklaim mengharuskan pembentukan koneksi, validasi JWT, dan cache sidecar untuk mengamati pembaruan dalam waktu lima menit. Koneksi panjang memerlukan pengosongan berbasis usia sertifikat berbatas; mengubah database control plane tanpa menangani koneksi yang ada bukanlah penyelesaian pencabutan.

Langkah 8: Rencanakan skala, kegagalan, dan migrasi

Penggunaan sumber daya SPIRE Server bertumbuh seiring dengan entri registrasi, dan satu instans merupakan titik kegagalan tunggal. Lakukan sharding berdasarkan region atau trust domain, gunakan beberapa Server untuk HA, batasi entri mana yang diterima setiap Agent, dan pantau latensi penerbitan, jumlah Agent, jumlah entri, permintaan Workload API, dan kelambatan (lag) bundle. Hindari grafik federasi yang terhubung penuh (fully meshed); gunakan edge atau broker terkontrol.

Ketika control plane tidak tersedia, SVID yang belum kedaluwarsa dapat mendukung koneksi berisiko rendah yang ada dalam batas waktu tertentu, tetapi sistem tidak boleh menerbitkan identitas selamanya. Bundle yang kedaluwarsa, bukti node yang gagal, kegagalan pengelola kunci, atau pemetaan domain yang tidak diketahui harus fail-closed untuk koneksi baru berisiko tinggi. Selama migrasi rahasia statis, jalankan kedua jalur, lakukan canary berdasarkan service pool, verifikasi audit dan pencabutan, lalu hapus rahasia lama. Rollback kembali ke jalur yang masih terkontrol, tidak pernah ke autentikasi yang dinonaktifkan.

Contoh jawaban berkualitas tinggi

“Saya akan memisahkan lingkungan production, staging, dan partner ke dalam trust domain yang berbeda serta menggunakan SPIFFE ID yang stabil untuk workload. Setiap SPIRE Server memiliki entri registrasi dan root penerbit. Sebuah Agent membuktikan nodenya, kemudian Workload API lokal menggunakan atribut proses dan orchestrator untuk atestasi workload. Workload memperoleh X.509-SVID berumur pendek untuk mTLS atau JWT-SVID untuk audience tetap; kunci privat tetap berada di workload, Agent, atau pengelola kunci terkontrol.

Pembayaran dan pelaporan memiliki satu edge federasi yang ditinjau. Klien mem-pin endpoint dan domain serta memvalidasi TLS, versi bundle, dan masa kedaluwarsa. Validasi peer memilih foreign bundle berdasarkan trust domain SVID dan menolak jika tidak cocok. Pelaporan memvalidasi SVID, penerbit, audience, dan kedaluwarsa, lalu mengotorisasi SPIFFE ID lengkap, tenant, dan tindakan. Federasi menyediakan materi verifikasi; federasi tidak memberikan izin bisnis.

SVID dan bundle berotasi melalui stream, TTL pendek, metrik versi, dan materi basi yang berbatas; koneksi panjang dikosongkan berdasarkan usia sertifikat. Kegagalan bukti atau control plane tidak pernah menerbitkan identitas yang tidak dikenal, dan panggilan berisiko tinggi akan fail-closed. Migrasi rahasia statis menggunakan jalur paralel, canary, latihan pencabutan, dan rekonsiliasi audit hingga setiap layanan dapat mendemonstrasikan batasan identitas, otorisasi, dan pemulihan.”

Kesalahan umum

Berbagi satu trust domain di setiap klaster. Satu kebocoran root atau konfigurasi akan berdampak ke setiap lingkungan; pisahkan domain berdasarkan tata kelola dan risiko.
Memperlakukan SPIFFE ID sebagai otorisasi bisnis. Identitas menjawab siapa; layanan sumber daya tetap memeriksa audience, tenant, tindakan, dan kepemilikan.
Hanya melakukan atestasi node. Proses berbahaya pada node dapat meniru identitas suatu layanan; gunakan juga selector workload.
Menggunakan nama pod atau IP yang dapat berubah sebagai prinsipal berumur panjang. Pembangunan ulang (rebuild) dan pemindahan mematahkan otorisasi; gunakan ID yang stabil dan selector kebijakan.
Memperlakukan URL federasi sebagai trust root. Konfigurasikan domain sebelumnya dan validasi TLS, konten bundle, versi, dan masa kedaluwarsa.
Mengizinkan setiap prinsipal eksternal dari foreign bundle. Federasi menyediakan materi verifikasi; kebijakan harus membatasi awalan ID, audience, tindakan, dan tenant.
Menempatkan kunci privat berumur panjang dalam image atau variabel lingkungan. Salinan membuatnya rentan terekspos; buat dan rotasikan pada batasan workload atau pengelola kunci.
Menerima bundle atau SVID yang basi selamanya. Hal itu melanggar prinsip pencabutan; lacak versi, TTL, dan usia koneksi serta tolak setelah batas waktu terlewati.
Melakukan default-allow selama pemadaman control plane. Identitas yang tidak diketahui tidak boleh mendapatkan otoritas; gunakan materi lama yang berbatas atau fail-closed berdasarkan risiko.
Memigrasikan mTLS tanpa audit dan otorisasi. Enkripsi tidak membuktikan izin bisnis; catat peer ID, versi kebijakan, tenant, dan keputusan.

Pertanyaan lanjutan dan jawaban

Jika dua trust domain memerlukan komunikasi dua arah, apakah keduanya harus mengimpor bundle satu sama lain?

Tidak selalu. Jika pembayaran hanya memanggil pelaporan, buat edge satu arah: pelaporan memercayai foreign bundle pembayaran, sedangkan pembayaran tidak perlu memercayai pelaporan. Tambahkan edge sebaliknya hanya jika pelaporan juga menginisiasi panggilan, dengan audience dan kebijakan terpisah. Kepercayaan timbal balik bukanlah izin penuh.

Mengapa tidak menggunakan identitas workload penyedia cloud secara langsung?

Identitas cloud berguna di dalam satu control plane cloud, tetapi lingkungan multi-cloud, privat, dan partner memiliki penerbit, SDK, dan kebijakan yang berbeda. SPIFFE menyediakan penamaan portabel, SVID, dan pertukaran bundle. IAM cloud eksternal tetap dapat menggunakan broker federasi OIDC terbatas; SPIFFE tidak menggantikan otorisasi bisnis.

Apakah Workload API yang tidak diautentikasi aman?

API ini mengandalkan identifikasi proses out-of-band alih-alih memperlakukan socket sebagai API jaringan terbuka. Batasi izin socket atau endpoint, isolasi host dan namespace, dan cocokkan entri registrasi terhadap fakta kernel, kubelet, atau container-runtime. Pemanggil yang tidak dapat diidentifikasi akan menerima penolakan, tidak pernah menerima SVID default berkekuatan tinggi.

Bagaimana jika endpoint foreign bundle tidak tersedia untuk sementara?

Simpan bundle tepercaya terakhir beserta versi dan masa kedaluwarsanya. Bundle tersebut dapat memvalidasi koneksi berisiko rendah yang ada selama masih segar; melebihi batas usia basi maksimum atau untuk koneksi baru berisiko tinggi, lakukan fail-closed. Pantau kelambatan bundle, versi sukses terakhir, dan penolakan alih-alih menerima root lama tanpa batas.

Bagaimana koneksi berumur panjang menangani rotasi dan pencabutan SVID?

Workload API men-stream materi baru; klien memperbarui secara atomik dan menggunakan sertifikat baru untuk koneksi baru. Kosongkan koneksi berdasarkan usia sertifikat maksimum atau jendela pencabutan, dan periksa kembali kebijakan sebelum commit berisiko tinggi. Mengganti file tanpa menangani koneksi yang sudah terbentuk tidak membuktikan bahwa identitas lama telah hilang.

Bagaimana Anda membuktikan bahwa selector tidak dapat dipalsukan?

Selector berasal dari API node atau orchestrator tepercaya dan diverifikasi oleh Server atau Agent. Label yang dapat diedit pengguna hanyalah petunjuk. Gabungkan image digest, service account, namespace, properti proses, dan bukti node, serta audit dan setujui perubahan registrasi.

Bagaimana cara Anda me-rollback migrasi rahasia statis?

Terima rahasia lama dan SVID secara paralel, aktifkan SVID berdasarkan service pool, dan catat keberhasilan, otorisasi, serta pencabutan untuk kedua jalur. Jika terjadi kegagalan, hentikan penerbitan baru dan kembali ke rahasia lama yang masih terkontrol, lalu lanjutkan canary setelah masalah diperbaiki. Tentukan bukti penghentian (retirement evidence) dan gerbang penghapusan (deletion gate); jangan pernah menonaktifkan autentikasi sebagai cara rollback.