Temu duga reka bentuk sistem: Bagaimanakah anda akan mereka bentuk identiti beban kerja SPIFFE yang difederasikan?

Masalah dan konteks

Sebuah syarikat menjalankan perkhidmatan mikro berbilang penyewa dalam dua awan dan satu kluster persendirian. Pasukan yang berbeza mengendalikan setiap persekitaran, dan persekitaran pengeluaran (production) mesti kekal terasing daripada persekitaran pementasan (staging). Perkhidmatan pembayaran memanggil perkhidmatan pelaporan, tetapi rahsia API yang tahan lama dan peranan khusus awan tidak boleh disalin ke dalam imej. Reka bentuk identiti beban kerja yang difederasikan merentas domain amanah.

Beban kerja memerlukan identiti yang berjangka hayat pendek dan boleh disahkan. Penerima mesti hanya mempercayai domain amanah luar, ID SPIFFE, khalayak (audiences), dan tindakan perniagaan yang diluluskan. Cakupi penamaan ID SPIFFE, SPIRE Server dan Agent, pengesahan nod dan beban kerja, X.509-SVID atau JWT-SVID, pengambilan berkas asing, pemetaan pembenaran, putaran, pembatalan, penimbalan (caching), pemulihan bencana, dan migrasi daripada kelayakan statik.

Kekalkan invarian berikut:

1. Sumber identiti membuktikan proses terkawal mana yang sedang berjalan, bukan sekadar bahawa sesebuah mesin mempunyai alamat rangkaian.
2. Berkas domain amanah tidak secara automatik memberikan autoriti tempatan kepada setiap beban kerja luar.
3. Penerima berhenti menerima SVID yang telah tamat tempoh atau dibatalkan dalam had yang diisytiharkan.
4. Kunci persendirian dijana oleh beban kerja atau pengurus kunci yang terkawal; satah kawalan (control plane) tidak mengedarkan kunci persendirian yang tahan lama.
5. Pemfederasian bertukar bahan identiti dan amanah; perkhidmatan sumber masih melakukan pembenaran perniagaan.

Perkara yang dinilai oleh penemu duga

Jawapan yang kukuh membezakan sempadan antara domain amanah, ID SPIFFE, SVID, SPIRE Server, Agent, dan API Beban Kerja. SPIFFE mentakrifkan penamaan identiti dan dokumen yang boleh disahkan; SPIRE melaksanakan pengesahan nod dan beban kerja serta pengeluaran SVID. Identiti bukanlah kebenaran: spiffe://prod.example/ns/payments/sa/worker masih memerlukan dasar pembenaran (allow policy) pada perkhidmatan pelaporan.

Isyarat kedua ialah pemfederasian. SPIFFE Federation bertukar bahan amanah awam melalui titik akhir berkas yang dikonfigurasikan dan disahkan dengan TLS. Penerima mesti mengetahui domain amanah mana yang diwakili oleh URL tersebut; ia tidak boleh memuat turun punca (root) bagi domain sewenang-wenangnya daripada sesuatu permintaan. API Beban Kerja boleh mengembalikan berkas asing, dan pengesah memilih berkas yang sepadan dengan domain amanah SVID tersebut.

Isyarat ketiga ialah rantaian bukti. Pengesahan nod membuktikan nod milik Agent, dan pengesahan beban kerja memadankan atribut kernel, kubelet, atau masa jalan bekas (container-runtime) yang dipercayai dengan pemilih (selectors) pendaftaran. Ruang nama (namespace), label, atau identiti klien yang diisytiharkan sendiri sahaja tidak mencukupi untuk menangani kelayakan perkhidmatan yang dicuri.

Akhir sekali, bincangkan operasi: berkas pemfederasian yang tamat tempoh, putaran kunci punca, Agent yang terputus sambungan, cache lapuk, titik kegagalan tunggal pada satah kawalan, penyelewengan jam rentas awan, perkhidmatan legasi yang tidak dapat memuatkan SVID, dan pengunduran (rollback) tanpa melumpuhkan pengesahan.

Soalan untuk dijelaskan terlebih dahulu

• Domain amanah mana yang benar-benar memerlukan amanah? Jika pembayaran hanya memanggil laporan, jangan bina graf amanah berjejaring penuh (fully meshed); tentukan pinggir satu arah atau minimum.
• X.509-SVID atau JWT-SVID? mTLS dan identiti sambungan sesuai untuk pautan perkhidmatan jangka panjang; HTTP rentas awan atau sumber OIDC luaran mungkin memerlukan khalayak JWT. Cache pengesahan dan tetingkap kebocoran kedua-duanya berbeza.
• Siapa yang mengendalikan titik akhir berkas asing? Satu syarikat boleh berkongsi tadbir urus; syarikat yang berbeza memerlukan bahan awam yang eksplisit, identiti TLS, dan pemetaan domain yang disemak.
• Apakah sasaran pembatalan? Contohnya, jangka hayat SVID maksimum 15 minit, tinjauan (polling) berkas 60 saat, dan sekatan sambungan baharu selama lima minit selepas pembatalan kecemasan.
• Bagaimanakah beban kerja membuktikan dirinya? Kubernetes ServiceAccount, dokumen instans awan, TPM, dan token penyertaan sekali guna yang terkawal mempunyai andaian yang berbeza.
• Bolehkah perkhidmatan legasi menggunakan SPIFFE? Jika tidak, bolehkah sidecar atau get laluan menterjemah secara terhad? Identiti dan kebenarannya memerlukan sempadannya sendiri.

Jawapan 30 saat

“Saya akan mencipta domain amanah bebas untuk pengeluaran, pementasan dan premis tempatan (on-prem) serta menetapkan ID SPIFFE stabil yang tidak mengandungi rahsia penyewa. SPIRE Server setiap domain memiliki entri pendaftaran. Agent membuktikan nodnya, kemudian menggunakan atribut proses tempatan untuk pengesahan beban kerja; beban kerja memperoleh X.509-SVID atau JWT-SVID berjangka hayat pendek daripada API Beban Kerja.

Domain pembayaran hanya akan mengkonfigurasi titik akhir berkas asing domain pelaporan dan menyematkan domain, identiti TLS, serta pemetaan yang dibenarkan. Pelaporan mengesahkan tandatangan, tamat tempoh SVID, khalayak, dan berkas rakan sebaya (peer bundle), kemudian membenarkan ID SPIFFE penuh, persekitaran, konteks penyewa, dan tindakan. Kemas kini berkas dan SVID menggunakan API penstriman, TTL pendek, dan metrik versi. Jika satah kawalan tidak tersedia, bahan yang disahkan sebelum ini secara terhad boleh melayani trafik berisiko rendah, tetapi sambungan baharu berisiko tinggi gagal-tutup (fail closed). Migrasi menjalankan kelayakan lama dan SVID secara selari, menggunakan canary mengikut kumpulan perkhidmatan, dan memadamkan rahsia hanya selepas sasaran audit dan pembatalan terbukti.”

Reka bentuk langkah demi langkah

Langkah 1: Pisahkan domain amanah dan namakan identiti

Domain amanah ialah ruang nama identiti dan sempadan punca amanah (root-of-trust). Persekitaran pengeluaran, pementasan, PCI, atau organisasi yang ditadbir secara berasingan harus menggunakan domain berasingan dan bukannya satu punca global. Contoh ID:

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

Laluan harus menyatakan prinsipal perniagaan dan skop tadbir urus yang stabil, bukan nama pod, IP, atau cincangan (hash) penggunaan berjangka hayat pendek. Versi, penyewa, dan rantau boleh menjadi pemilih, input dasar, atau tuntutan token. Mengekodkan setiap penggunaan ke dalam ID mengubah penyelenggaraan putaran dan pembenaran menjadi migrasi seluruh armada.

Rekodkan pemfederasian sebagai pinggir eksplisit: prod.example boleh mengesahkan berkas reports.partner, tetapi hanya untuk khalayak reports-api dan tindakan ReportRead. Penerima tidak boleh membenarkan panggilan semata-mata kerana kedua-dua domain menggunakan SPIFFE.

Langkah 2: Sediakan Server, Agent, dan entri pendaftaran

SPIRE Server menyimpan entri pendaftaran, bahan tandatangan, dan pembenaran nod. Agent berjalan pada setiap nod beban kerja dan mendedahkan API Beban Kerja tempatan. Server menghantar kepada Agent hanya entri yang dibenarkan untuk diuruskan oleh Agent tersebut, mengehadkan jejari letupan (blast radius) bagi satu kompromi nod.

Sesuatu entri harus mengikat ID SPIFFE, ID SPIFFE induk, set pemilih, profil SVID yang dibenarkan, dan khalayak. Pemilih datang daripada orkestrator yang dipercayai atau sifat nod: ruang nama Kubernetes, akaun perkhidmatan, pelekat imej (image digest), atau identiti instans awan. Jangan hanya bergantung pada label yang boleh diedit pengguna atau menganggap rentetan konfigurasi sewenang-wenangnya sebagai bukti pengesahan.

Langkah 3: Reka bentuk pengesahan dua peringkat

Semasa permulaan nod, Agent membuktikan identitinya dengan dokumen instans awan, Kubernetes ServiceAccount, TPM, atau token penyertaan sekali guna. Server mengesahkan bukti tersebut secara bebas dan mengeluarkan identiti Agent. Beban kerja kemudian memanggil API Beban Kerja melalui soket domain Unix atau titik akhir terhad. Agent menggunakan ID proses, fakta kernel, kubelet, atau masa jalan bekas untuk mendapatkan pemilih, memadankan entri pendaftaran, dan mengembalikan SVID.

Ini menjelaskan sebab API Beban Kerja tidak perlu menggunakan pengesahan klien rangkaian biasa: Agent mengenal pasti pemanggil tempatan di luar jalur (out of band). Keizinan soket, pengasingan ruang nama, dan kepercayaan pada kernel hos atau kubelet termasuk dalam model ancaman. Jika Agent tidak dapat mengenal pasti pemanggil, ia harus mengembalikan PermissionDenied dan bukannya identiti lalai dengan keistimewaan tinggi.

Langkah 4: Pilih profil SVID dan kendalikan kunci

X.509-SVID sesuai untuk mTLS dan identiti perkhidmatan peringkat sambungan. JWT-SVID sesuai untuk pertukaran HTTP atau OIDC luaran di mana audience mesti dibawa bersama perakuan. Pengesah JWT-SVID mesti menggunakan berkas untuk domain amanah subjek; JWKS sewenang-wenangnya bukanlah punca amanah yang sama.

SVID harus berjangka hayat pendek dan distrim melalui API Beban Kerja. Beban kerja atau pengurus kunci Agent menjana kunci persendirian dan menyimpannya dalam ingatan terhad atau deskriptor fail. Server menandatangani kunci awam yang sepadan tetapi tidak pernah menulis kunci persendirian jangka panjang ke dalam imej, pemboleh ubah persekitaran, atau konfigurasi biasa. Beban kerja dengan pelbagai identiti boleh menggunakan hint atau pemilihan eksplisit untuk khalayak dalaman dan luaran supaya tetapan lalai tidak boleh disalahgunakan.

Langkah 5: Wujudkan pemfederasian berkas rentas domain dengan selamat

Satah kawalan pemfederasian menyemak domain asing, titik akhir berkas, profil titik akhir, sijil TLS, dan awalan ID SPIFFE yang dibenarkan. Klien mengetahui terlebih dahulu domain amanah mana yang diwakili oleh URL tersebut. Pengesahan TLS membuktikan titik akhir pengangkutan; berkas yang dikembalikan masih memerlukan pemeriksaan domain, versi, tandatangan, dan tamat tempoh.

Simpan berkas asing dalam stor amanah berversi. Semasa pengesahan rakan sebaya, pilih berkas mengikut domain amanah SVID; tolak jika padanan tiada. Jangan jadikan berkas asing sebagai punca pengeluar tempatan, dan jangan gantikan konfigurasi secara kekal disebabkan oleh pengalihan sementara. Tinjauan, ETag, tamat tempoh, dan versi berjaya terakhir harus boleh diperhatikan.

Langkah 6: Petakan identiti kepada pembenaran sumber

PEP perkhidmatan pelaporan mengesahkan rakan sebaya mTLS atau JWT-SVID, kemudian menghantar ID SPIFFE penuh, domain amanah, khalayak, penyewa, dan tindakan kepada PDP. Contoh peraturan ialah:

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

Kebolehcapaian rangkaian, SVID yang sah, dan pinggir pemfederasian bukanlah kebenaran perniagaan. Perkhidmatan sumber masih memeriksa pemilikan penyewa, akses peringkat baris, kelulusan, dan had kadar (rate limits). Jika identiti beban kerja mesti mencapai IAM awan atau perkhidmatan OIDC luaran, gunakan broker terhad yang terikat pada khalayak, skop, TTL SVID, dan tujuan; jangan sekali-kali memberikan satu peranan awan yang luas kepada setiap beban kerja.

Langkah 7: Selaraskan putaran, pembatalan, dan ketekalan cache

Tamat tempoh SVID dikendalikan melalui strim API Beban Kerja. Klien menggantikan sijil dan kunci secara atomik dan membiarkan sambungan baharu menggunakan bahan baharu terlebih dahulu. Putaran berkas amanah menggunakan pertindihan terikat antara punca lama dan baharu; alih keluar punca lama hanya selepas pengesah memuatkan versi baharu dan SVID serta sambungan lama telah dikosongkan (drained). Kompromi kecemasan tidak menggunakan pertindihan biasa; terbitkan versi pembatalan atau penafian dan pendekkan tetingkap penerimaan.

Simpan dalam cache versi berkas, pengeluar, domain amanah, tamat tempoh SVID, dan versi dasar. Objektif pembatalan lima minit yang dituntut memerlukan pembentukan sambungan, pengesahan JWT, dan cache sidecar untuk melihat kemas kini dalam masa lima minit. Sambungan panjang memerlukan pengosongan berasaskan usia sijil terikat; menukar pangkalan data satah kawalan tanpa mengendalikan sambungan sedia ada bukanlah penyelesaian pembatalan.

Langkah 8: Rancang skala, kegagalan, dan migrasi

Penggunaan sumber SPIRE Server meningkat mengikut entri pendaftaran, dan satu instans merupakan titik kegagalan. Lakukan pemecahan (sharding) mengikut rantau atau domain amanah, gunakan berbilang Server untuk ketersediaan tinggi (HA), hadkan entri yang diterima oleh setiap Agent, dan pantau kependaman pengeluaran, bilangan Agent, bilangan entri, permintaan API Beban Kerja, dan kelambatan berkas. Elakkan graf pemfederasian berjejaring penuh; gunakan pinggir atau broker terkawal.

Apabila satah kawalan tidak tersedia, SVID yang belum tamat tempoh boleh menyokong sambungan sedia ada berisiko rendah yang terikat, tetapi sistem tidak boleh mengeluarkan identiti selama-lamanya. Berkas yang tamat tempoh, bukti nod yang gagal, kegagalan pengurus kunci, atau pemetaan domain yang tidak diketahui harus gagal-tutup untuk sambungan baharu berisiko tinggi. Semasa migrasi rahsia statik, jalankan kedua-dua laluan, gunakan canary mengikut kumpulan perkhidmatan, sahkan audit dan pembatalan, dan kemudian padamkan rahsia lama. Pengunduran (rollback) kembali ke laluan yang masih terkawal, tidak sekali-kali kepada pengesahan yang dilumpuhkan.

Contoh jawapan berkualiti tinggi

“Saya akan mengasingkan persekitaran pengeluaran, pementasan dan rakan kongsi kepada domain amanah dan menggunakan ID SPIFFE yang stabil untuk beban kerja. Setiap SPIRE Server memiliki entri pendaftaran dan punca pengeluaran. Agent membuktikan nodnya, kemudian API Beban Kerja tempatan menggunakan atribut proses dan orkestrator untuk pengesahan beban kerja. Beban kerja memperoleh X.509-SVID berjangka hayat pendek untuk mTLS atau JWT-SVID untuk khalayak tetap; kunci persendirian kekal dengan beban kerja, Agent, atau pengurus kunci terkawal.

Pembayaran dan laporan mempunyai satu pinggir pemfederasian yang disemak. Klien menyematkan titik akhir dan domain serta mengesahkan TLS, versi berkas, dan masa tamat tempoh. Pengesahan rakan sebaya memilih berkas asing mengikut domain amanah SVID dan menolak jika tiada padanan. Pelaporan mengesahkan SVID, pengeluar, khalayak, dan tamat tempoh, kemudian membenarkan ID SPIFFE penuh, penyewa, dan tindakan. Pemfederasian menyediakan bahan pengesahan; ia tidak memberikan kebenaran perniagaan.

SVID dan berkas berputar melalui strim, TTL pendek, metrik versi, dan bahan lapuk terikat; sambungan panjang dikosongkan mengikut usia sijil. Kegagalan bukti atau satah kawalan tidak sekali-kali mengeluarkan identiti yang tidak diketahui, dan panggilan berisiko tinggi gagal-tutup. Migrasi rahsia statik menggunakan laluan selari, canary, latih tubi pembatalan, dan penyelarasan audit sehingga setiap perkhidmatan dapat menunjukkan sempadan identiti, pembenaran, dan pemulihan.”

Kesilapan lazim

• Berkongsi satu domain amanah merentas setiap klaster. Satu punca atau kebocoran konfigurasi mencapai setiap persekitaran; bahagikan domain mengikut tadbir urus dan risiko.
• Menganggap ID SPIFFE sebagai pembenaran perniagaan. Identiti menjawab siapa; perkhidmatan sumber masih memeriksa khalayak, penyewa, tindakan, dan pemilikan.
• Hanya melakukan pengesahan nod. Proses berniat jahat pada nod boleh menyamar sebagai perkhidmatan; gunakan pemilih beban kerja juga.
• Menggunakan nama pod atau IP yang boleh berubah sebagai prinsipal jangka panjang. Pembinaan semula dan pergerakan memecahkan pembenaran; gunakan ID stabil dan pemilih dasar.
• Menganggap URL pemfederasian sebagai punca amanah. Pra-konfigurasikan domain dan sahkan TLS, kandungan berkas, versi, dan tamat tempoh.
• Membenarkan setiap prinsipal luar daripada berkas asing. Pemfederasian membekalkan bahan pengesahan; dasar mesti mengehadkan awalan ID, khalayak, tindakan, dan penyewa.
• Meletakkan kunci persendirian jangka panjang dalam imej atau pemboleh ubah persekitaran. Salinan mendedahkannya; jana dan putarkan pada sempadan beban kerja atau pengurus kunci.
• Menerima berkas atau SVID lapuk selama-lamanya. Itu melanggar pembatalan; jejaki versi, TTL, dan usia sambungan serta tolak selepas had terlampaui.
• Membenarkan secara lalai (default-allowing) semasa gangguan satah kawalan. Identiti yang tidak diketahui tidak boleh memperoleh autoriti; gunakan bahan lama terikat atau gagal-tutup mengikut risiko.
• Memindahkan mTLS tanpa audit dan pembenaran. Penyulitan tidak membuktikan kebenaran perniagaan; rekodkan ID rakan sebaya, versi dasar, penyewa, dan keputusan.

Soalan susulan dan jawapan

Jika dua domain amanah memerlukan komunikasi dwiarah, adakah kedua-duanya mesti mengimport berkas satu sama lain?

Tidak semestinya. Jika pembayaran hanya memanggil laporan, buat pinggir satu arah: laporan mempercayai berkas asing pembayaran, manakala pembayaran tidak perlu mempercayai laporan. Tambah pinggir songsang hanya apabila laporan juga memulakan panggilan, dengan khalayak dan dasar yang berasingan. Amanah bersama bukanlah kebenaran penuh.

Mengapa tidak menggunakan identiti beban kerja penyedia awan secara langsung?

Identiti awan berguna dalam satu satah kawalan awan, tetapi persekitaran berbilang awan, persendirian, dan rakan kongsi mempunyai pengeluar, SDK, dan dasar yang berbeza. SPIFFE membekalkan penamaan mudah alih, SVID, dan pertukaran berkas. IAM awan luaran masih boleh menggunakan broker pemfederasian OIDC terhad; SPIFFE tidak menggantikan pembenaran perniagaan.

Adakah API Beban Kerja tanpa pengesahan selamat?

Ia bergantung pada pengenalpastian proses di luar jalur dan bukannya memperlakukan soket sebagai API rangkaian terbuka. Hadkan keizinan soket atau titik akhir, asingkan hos dan ruang nama, dan padankan entri pendaftaran dengan fakta kernel, kubelet, atau masa jalan bekas. Pemanggil yang tidak dapat dikenal pasti menerima penafian, tidak sekali-kali SVID berkuasa lalai.

Bagaimana jika titik akhir berkas asing tidak tersedia buat sementara waktu?

Kekalkan berkas dipercayai terakhir dengan versi dan masa tamat tempoh. Ia boleh mengesahkan sambungan berisiko rendah sedia ada semasa masih baharu; melangkaui usia lapuk maksimum atau untuk sambungan baharu berisiko tinggi, gagal-tutup. Pantau kelambatan berkas, versi berjaya terakhir, dan penafian dan bukannya menerima punca lama selama-lamanya.

Bagaimanakah sambungan jangka panjang mengendalikan putaran dan pembatalan SVID?

API Beban Kerja menstrim bahan baharu; klien mengemas kini secara atomik dan menggunakan sijil baharu untuk sambungan baharu. Kosongkan mengikut usia sijil maksimum atau tetingkap pembatalan, dan semak semula dasar sebelum komit berisiko tinggi. Menggantikan fail tanpa mengendalikan sambungan yang telah diwujudkan tidak membuktikan identiti lama telah tiada.

Bagaimanakah anda membuktikan pemilih tidak boleh dipalsukan?

Pemilih datang daripada API nod atau orkestrator yang dipercayai dan disahkan oleh Server atau Agent. Label yang boleh diedit pengguna hanyalah petunjuk. Gabungkan pelekat imej, akaun perkhidmatan, ruang nama, sifat proses, dan bukti nod, serta audit dan luluskan perubahan pendaftaran.

Bagaimanakah anda mengundurkan (rollback) migrasi rahsia statik?

Terima rahsia lama dan SVID secara selari, dayakan SVID mengikut kumpulan perkhidmatan, dan rekodkan kejayaan, pembenaran, dan pembatalan untuk kedua-dua laluan. Sekiranya berlaku kegagalan, hentikan pengeluaran baharu dan kembali kepada rahsia lama yang masih terkawal, kemudian teruskan canary selepas membetulkan isu tersebut. Tentukan bukti penamatan dan get pemadaman; jangan sekali-kali melumpuhkan pengesahan sebagai langkah pengunduran.