1. Skenario, sasaran, dan non-sasaran
Tim infrastruktur mengoperasikan Gateway bersama sementara tim aplikasi men-deploy layanan di namespace mereka masing-masing. Layanan pembayaran mengharuskan Gateway tidak pernah melihat plaintext, layanan manajemen internal memerlukan validasi sertifikat klien di edge, dan auditor mewajibkan perubahan rute serta kegagalan handshake dicatat. Tim harus dapat memublikasikan rute secara independen sementara izin sertifikat, backend, dan listener tetap dibatasi.
Nyatakan non-sasaran terlebih dahulu: sumber daya Gateway API mengekspresikan niat (intent). Implementasi TLS konkret, perilaku load-balancing, dan penyimpanan sertifikat tetap merupakan properti dari pengontrol GatewayClass. Oleh karena itu, rancangan ini membutuhkan matriks kapabilitas pengontrol dan pemeriksaan kompatibilitas; perilaku dari satu implementasi tidak dapat diperlakukan sebagai jaminan API.
2. Mendekomposisi kapabilitas Gateway API 1.5
Gateway API 1.5 memindahkan TLSRoute, validasi sertifikat klien frontend, dan kapabilitas backend TLS terkait menuju dukungan yang stabil, serta mempromosikan ReferenceGrant ke v1. TLSRoute mencocokkan hostname dari SNI handshake TLS dan meneruskan koneksi ke backend; listener dapat menggunakan Passthrough atau Terminate.
Dalam Passthrough, Gateway memproksi byte terenkripsi dan backend memiliki sertifikat serta handshake. Dalam Terminate, TLS berakhir di Gateway dan TCP yang didekripsi dikirim ke backend. Kepemilikan kunci, visibilitas data, dan titik eksekusi kebijakan berbeda, sehingga performa saja tidak dapat menjadi penentu pilihan di antara keduanya.
3. Merancang sumber daya dan kepemilikan
Tim platform membuat Gateway dan listener; tim aplikasi membuat objek TLSRoute yang terikat ke listener bernama. Gunakan parentRefs.sectionName untuk mengikat rute ke listener eksplisit daripada membiarkan satu rute mengklaim seluruh Gateway. Hostname, port, protokol, dan referensi sertifikat adalah input kebijakan untuk ditinjau.
Pasangan sumber daya ini mengekspresikan niat passthrough:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-edge
namespace: infra
spec:
gatewayClassName: example-gateway-class
listeners:
- name: tls-passthrough
protocol: TLS
port: 8443
tls:
mode: Passthrough
---
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
name: payments
namespace: payments
spec:
parentRefs:
- name: shared-edge
namespace: infra
sectionName: tls-passthrough
hostnames: ["pay.example.com"]
rules:
- backendRefs:
- name: payments
port: 8443Referensi lintas-namespace harus lolos mekanisme otorisasi pengontrol dan secara eksplisit diizinkan oleh ReferenceGrant atau kebijakan yang setara. Jangan mengandalkan visibilitas default.
4. Memilih antara Passthrough dan Terminate
Passthrough berarti Gateway tidak memegang private key dan tidak melihat protokol aplikasi. Ini cocok untuk enkripsi end-to-end yang ketat, mutual TLS langsung ke backend, atau persyaratan TCP terenkripsi. Konsekuensinya (trade-off) adalah Gateway tidak dapat merutekan berdasarkan konten HTTP, menerapkan batasan lapisan aplikasi yang seragam, atau memvalidasi sertifikat klien di edge; backend menanggung pekerjaan handshake dan rotasi sertifikat.
Terminate memusatkan manajemen sertifikat dan memungkinkan validasi sertifikat klien di edge, perutean yang konsisten, dan observabilitas yang konsisten. Konsekuensinya adalah visibilitas plaintext di Gateway. Jika lompatan ke backend harus tetap terenkripsi, konfigurasikan juga backend TLS; paparan private key dan domain kegagalan pengontrol juga bertambah.
Rancangan berstandar wawancara disusun berlapis: secara default tetapkan koneksi pembayaran yang sangat sensitif ke passthrough, sementara lakukan terminasi pada layanan manajemen yang membutuhkan identitas dan kebijakan terpusat, lalu lindungi lompatan kedua dengan backend TLS.
5. mTLS Frontend dan trust anchor
mTLS Frontend memvalidasi koneksi klien-ke-Gateway. Gateway memeriksa sertifikat klien terhadap bundel CA yang dikonfigurasi; mode strict hanya menerima klien yang tervalidasi. Fallback yang tidak aman dapat memungkinkan sertifikat yang hilang atau tidak valid mencapai backend, sehingga ini harus menjadi pengecualian eksplisit yang digabungkan dengan network policy dan peringatan audit.
Kelompokkan trust anchor berdasarkan tenant atau lingkungan. Distribusikan bundel CA melalui referensi Secret atau ConfigMap yang terkontrol. Tim aplikasi tidak boleh menerima referensi private key platform. Selama rotasi, publikasikan CA baru, amati jendela dual-trust, cabut CA lama, dan catat waktu serta cakupan aktivasi.
6. Otorisasi multi-tenant dan konflik
Listener pada Gateway bersama merupakan batas platform. Aplikasi seharusnya hanya meminta hostname dan backend yang disetujui. Pengontrol harus menolak hostname yang tumpang tindih, parentRefs yang tidak sah, backend lintas-namespace, serta port atau protokol di luar kebijakan, dan menampilkan alasannya di status sumber daya.
Validasi ReferenceGrant, referensi Secret, dan kapabilitas GatewayClass saat admission. Tinjau perubahan kebijakan di Git; pada runtime, pengontrol harus membuat konfigurasi hanya dari sumber daya yang disetujui. Jika terjadi konflik rute, pertahankan konfigurasi terakhir yang diketahui baik dan laporkan Accepted=False alih-alih membiarkan perilaku last-writer-wins menimpa tenant lain secara diam-diam.
7. Kegagalan, peningkatan versi, dan observabilitas
Sebelum peluncuran, pastikan bahwa pengontrol mendukung versi TLSRoute yang stabil, mode TLS yang dipilih, validasi klien, dan backend TLS. Peningkatan versi Gateway API mungkin memerlukan migrasi sumber daya eksperimental ke v1 yang stabil; mengganti URL YAML saja tidak cukup.
Pantau kecocokan SNI, conditions listener dan rute, masa kedaluwarsa sertifikat, alasan kegagalan sertifikat klien, kesalahan koneksi backend, latensi propagasi konfigurasi, serta metrik handshake dan lalu lintas per-tenant. Jaga agar bundel kepercayaan, status rute, dan health check backend tetap konsisten selama failover. Jika Gateway tidak tersedia, tentukan fallback DNS atau load balancer yang eksplisit alih-alih melewatinya dengan lalu lintas plaintext.
8. Rubrik dan pertanyaan lanjutan
Harus dijelaskan
- Bedakan perutean SNI TLSRoute dari batas kunci dan plaintext pada Passthrough dan Terminate.
- Rancang trust CA, rotasi, kebijakan kegagalan, dan otorisasi lintas-namespace untuk mTLS frontend.
- Jelaskan perbedaan kapabilitas pengontrol, conditions sumber daya, migrasi upgrade, dan observabilitas alih-alih hanya menempelkan YAML.
Pertanyaan lanjutan
- Jika dua namespace mengklaim SNI yang sama, bagaimana Anda mencegah penimpaan diam-diam (silent overwrite)?
- Setelah Gateway menghentikan (terminate) TLS, bagaimana Anda menjamin bahwa lompatan kedua tetap menggunakan enkripsi yang patuh?
- Selama rotasi CA klien, bagaimana Anda mendukung sertifikat ganda sambil membatasi masa pakai maksimum sertifikat lama?
Panduan penilaian
Jawaban yang sangat baik menghubungkan kepemilikan sumber daya, batas enkripsi, otorisasi, dan bukti runtime: putuskan siapa yang memegang setiap kunci, tolak konflik dengan status conditions, dan buktikan kebijakan dengan metrik handshake, sertifikat, dan backend.