Wawancara Backend: Bagaimana Anda akan menggunakan Gateway API BackendTLSPolicy?

Petunjuk dan konteks

Sebuah Gateway kluster menerima HTTPS eksternal dan meneruskan permintaan ke Service internal yang hanya menerima TLS. Jelaskan cara menggunakan Gateway API BackendTLSPolicy untuk mengonfigurasi TLS upstream, memvalidasi sertifikat dan nama host, serta menangani kebijakan yang tidak valid, referensi lintas namespace, dan rollback.

Apa yang sedang diuji oleh pewawancara

Membedakan terminasi TLS klien dari inisiasi TLS Gateway-ke-backend.
Memahami bahwa kebijakan terpasang ke Service melalui referensi target dan melaporkan status melalui implementasi.
Menjelaskan CA, nama server, sertifikat klien, dan risiko melewati verifikasi.
Memperhitungkan otorisasi lintas namespace, kompatibilitas, observabilitas, rollback, dan migrasi bertahap.

Pertanyaan klarifikasi yang perlu diajukan

Apakah TLS berakhir di Gateway dan dimulai kembali, atau lewat secara end-to-end? Nama layanan mana yang ada di SAN sertifikat backend?
Namespace mana yang memiliki CA, sertifikat klien, dan private key, serta apakah ReferenceGrant atau otorisasi lain diperlukan?
Apakah implementasi Gateway mendukung versi BackendTLSPolicy dan tipe Route target saat ini?
Bagaimana lalu lintas akan dipantau, diisolasi, dan di-rollback selama rotasi sertifikat, kebijakan yang tidak valid, atau pemadaman TLS backend?

Jawaban 30 detik

Saya akan memisahkan kedua segmen TLS: terminasi dari klien ke Gateway, dan TLS upstream dari Gateway ke Service. BackendTLSPolicy terpasang ke Service dan mendeklarasikan materi validasi ditambah identitas klien opsional; implementasi harus melaporkan apakah kebijakan tersebut valid. Sebelum peluncuran, saya akan memverifikasi CA, nama server, port, otorisasi lintas namespace, dan dukungan implementasi, tanpa pernah melewati pemeriksaan sertifikat. Saya akan melakukan canary pada satu backend, memantau status kebijakan, kesalahan handshake, serta masa kedaluwarsa, dan menyiapkan rollback yang dapat dibalikkan.

Pembahasan mendalam langkah demi langkah

1. Tentukan batas TLS

Panduan TLS Gateway API menempatkan konfigurasi TLS upstream dalam BackendTLSPolicy yang terpasang pada Service. Setelah terminasi TLS klien, Gateway bertindak sebagai klien TLS ke backend; sertifikat backend harus divalidasi terhadap materi kepercayaan yang dikonfigurasi dan nama servernya harus cocok dengan identitas sertifikat. Sertifikat listener eksternal bukanlah konfigurasi validasi backend.

2. Rancang pemasangan dan materi validasi

Referensi target kebijakan mengarah ke Service. Validasi dapat menggunakan referensi sertifikat CA atau opsi CA yang dikenal (well-known CA) yang ditentukan oleh spesifikasi. Jika backend memerlukan mutual TLS, konfigurasikan sertifikat klien dan key, serta batasi akses Secret. Contoh yang disederhanakan ini digunakan untuk mendiskusikan hubungan antar bidang; verifikasi versi API dan bidang yang didukung untuk implementasi tersebut:

yaml

apiVersion: gateway.networking.k8s.io/v1alpha3
kind: BackendTLSPolicy
metadata:
  name: payments-upstream-tls
spec:
  targetRefs:
    - group: ""
      kind: Service
      name: payments
  validation:
    hostname: payments.internal.example
    wellKnownCACertificates: System

Sebelum penerapan, periksa status kebijakan, objek yang direferensikan, dan alasan controller menyatakan tidak valid; pembuatan objek saja tidak membuktikan bahwa kebijakan tersebut aktif.

3. Tangani namespace dan rotasi sertifikat

Jaga agar batasan namespace antara kebijakan dan Service target tetap eksplisit. Referensi lintas namespace memerlukan mekanisme otorisasi yang didukung oleh implementasi; kemampuan Gateway untuk mencapai Service tidak memberikan izin untuk membaca Secret miliknya. Rotasi sertifikat dengan jendela tumpang tindih (overlap window) atau strategi dual-CA, amati keberhasilan handshake, lalu hentikan materi lama dan verifikasi bahwa koneksi dibangun kembali.

4. Amati, lakukan canary, dan rollback

Lakukan canary pada satu Service atau port terlebih dahulu. Catat status kebijakan, kegagalan handshake TLS, ketidakcocokan nama backend, kedaluwarsa, dan percobaan ulang koneksi. Ketika sebuah kebijakan menjadi tidak valid, perilaku yang aman adalah menolak koneksi yang tidak aman dan mengeluarkan peristiwa yang dapat didiagnosis, bukan secara diam-diam menurunkan ke teks biasa (plaintext). Rollback mengembalikan kebijakan atau target rute yang divalidasi terakhir dan mempertahankan catatan sertifikat serta audit.

Jawaban model

Pertama, saya akan mendefinisikan dua koneksi: TLS eksternal berakhir di Gateway, yang kemudian terhubung ke Service sebagai klien TLS. BackendTLSPolicy terpasang ke Service tersebut dan mendeklarasikan CA, nama server, dan sertifikat klien opsional; status controller adalah sinyal utama bahwa kebijakan tersebut efektif. Saya akan membatasi akses Secret dan lintas namespace serta memverifikasi dukungan API dan Route dari implementasi. Service canary akan menguji SAN sertifikat, kepercayaan CA, rotasi, kesalahan handshake, dan pembangunan ulang koneksi. Saya tidak akan pernah menganggap verifikasi yang dinonaktifkan sebagai sebuah perbaikan. Kebijakan yang tidak valid atau kegagalan sertifikat harus memblokir lalu lintas yang tidak aman, memicu peringatan, dan mengikuti rencana rollback.

Kesalahan umum

Hanya mengonfigurasi sertifikat klien-ke-Gateway dan melupakan inisiasi TLS upstream.
Mengarahkan targetRef ke objek yang salah atau berasumsi setiap controller mendukung versi API yang sama.
Mempercayai CA tanpa memvalidasi nama server sertifikat backend.
Menyembunyikan masalah CA, SAN, atau rotasi dengan melewati verifikasi atau fallback ke plaintext.
Mengizinkan pembacaan Secret lintas namespace tanpa batasan otorisasi dan audit.
Menganggap keberhasilan pembuatan sumber daya sebagai bukti, sambil mengabaikan status, metrik handshake, dan peristiwa controller.

Pertanyaan lanjutan dan tanggapan

Bagaimana BackendTLSPolicy berhubungan dengan terminasi TLS klien?

Terminasi TLS klien melindungi segmen peramban atau pemanggil ke Gateway; BackendTLSPolicy melindungi segmen Gateway ke Service. Keduanya dapat menggunakan sertifikat dan domain kepercayaan yang berbeda, sehingga identitas dan rotasi harus diverifikasi secara terpisah.

Bagaimana jika nama sertifikat backend tidak cocok?

Terbitkan sertifikat backend untuk nama server yang digunakan oleh Gateway, atau buat hostname kebijakan cocok dengan SAN sertifikat. Jangan nonaktifkan verifikasi nama; periksa DNS, SNI, penamaan Service, dan rantai sertifikat.

Bagaimana cara Anda merilis kebijakan yang tidak valid?

Hubungkan status tidak valid ke peringatan dan gerbang rilis (release gate), hentikan perluasan canary, dan periksa referensi, materi CA, izin Secret, dan dukungan implementasi. Lanjutkan hanya setelah status valid dan handshake berhasil; rollback darurat akan kembali ke kebijakan terakhir yang divalidasi.