Temuduga Backend: Bagaimanakah anda akan menggunakan Gateway API BackendTLSPolicy?

Gesaan dan konteks

Gateway kluster menerima HTTPS luaran dan memajukan permintaan ke Service dalaman yang hanya menerima TLS. Terangkan cara menggunakan Gateway API BackendTLSPolicy untuk mengkonfigurasi TLS huluan, mengesahkan sijil dan nama hos, serta mengendalikan dasar tidak sah, rujukan rentas ruang nama dan pengunduran (rollback).

Perkara yang sedang diuji oleh penemu duga

Membezakan penamatan TLS klien daripada permulaan TLS Gateway-ke-bahagian belakang (backend).
Memahami bahawa dasar dilampirkan pada Service melalui rujukan sasaran dan melaporkan status melalui pelaksanaan.
Menerangkan CA, nama pelayan, sijil klien, dan risiko melangkau pengesahan.
Mengambil kira kebenaran rentas ruang nama, keserasian, kebolehlihatan, pengunduran, dan migrasi berperingkat.

Soalan penjelasan untuk ditanya

Adakah TLS ditamatkan di Gateway dan dimulakan semula, atau melalui hujung-ke-hujung? Nama perkhidmatan manakah yang terdapat dalam SAN sijil bahagian belakang?
Ruang nama manakah yang memiliki CA, sijil klien, dan kunci peribadi, dan adakah ReferenceGrant atau kebenaran lain diperlukan?
Adakah pelaksanaan Gateway menyokong versi BackendTLSPolicy semasa dan jenis Route sasaran?
Bagaimanakah trafik akan diperhatikan, diasingkan, dan diundur semasa putaran sijil, dasar tidak sah, atau gangguan TLS bahagian belakang?

Jawapan 30 saat

Saya akan memisahkan dua bahagian TLS: penamatan dari klien ke Gateway, dan TLS huluan dari Gateway ke Service. BackendTLSPolicy dilampirkan pada Service dan mengisytiharkan bahan pengesahan serta identiti klien pilihan; pelaksanaan mesti melaporkan sama ada dasar tersebut sah. Sebelum pelancaran, saya akan mengesahkan CA, nama pelayan, port, kebenaran rentas ruang nama, dan sokongan pelaksanaan, tanpa sesekali memintas pemeriksaan sijil. Saya akan melaksanakan canary pada satu bahagian belakang, memantau status dasar, ralat jabat tangan (handshake), dan tamat tempoh, serta menyediakan pengunduran yang boleh diterbalikkan.

Perbincangan mendalam langkah demi langkah

1. Tentukan sempadan TLS

Panduan TLS Gateway API meletakkan konfigurasi TLS huluan dalam BackendTLSPolicy yang dilampirkan pada Service. Selepas penamatan TLS klien, Gateway bertindak sebagai klien TLS ke bahagian belakang; sijil bahagian belakang mesti disahkan terhadap bahan amanah yang dikonfigurasi dan nama pelayannya mesti sepadan dengan identiti sijil. Sijil pendengar luaran bukanlah konfigurasi pengesahan bahagian belakang.

2. Reka bentuk lampiran dan bahan pengesahan

Rujukan sasaran dasar menunjuk ke Service. Pengesahan boleh menggunakan rujukan sijil CA atau pilihan CA terkenal yang ditentukan oleh spesifikasi. Jika bahagian belakang memerlukan mutual TLS, konfigurasikan sijil dan kunci klien serta hadkan akses Secret. Contoh ringkas ini adalah untuk membincangkan hubungan medan; sahkan versi API dan medan yang disokong untuk pelaksanaan:

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 penggunaan, periksa status dasar, objek yang dirujuk, dan sebab tidak sah pengawal; penciptaan objek sahaja tidak membuktikan bahawa dasar itu aktif.

3. Kendalikan ruang nama dan putaran sijil

Pastikan sempadan ruang nama dasar dan Service sasaran adalah jelas. Rujukan rentas ruang nama memerlukan mekanisme kebenaran yang disokong oleh pelaksanaan; keupayaan Gateway untuk mencapai Service tidak memberikan kebenaran untuk membaca Secret miliknya. Putar sijil dengan tetingkap pertindihan atau strategi dwi-CA, perhatikan kejayaan jabat tangan, kemudian henti guna bahan lama dan sahkan bahawa sambungan dibina semula.

4. Perhatikan, buat canary, dan undur

Lakukan canary pada satu Service atau port dahulu. Rekodkan status dasar, kegagalan jabat tangan TLS, ketidakpadanan nama bahagian belakang, tamat tempoh, dan percubaan semula sambungan. Apabila dasar menjadi tidak sah, tingkah laku yang selamat adalah menolak sambungan yang tidak selamat dan mengeluarkan peristiwa yang boleh didiagnosis, bukannya menurunkan taraf secara senyap kepada teks biasa. Pengunduran memulihkan dasar atau sasaran laluan terakhir yang disahkan dan mengekalkan rekod sijil serta audit.

Jawapan model

Saya akan menentukan dua sambungan terlebih dahulu: TLS luaran ditamatkan di Gateway, yang kemudiannya bersambung ke Service sebagai klien TLS. BackendTLSPolicy dilampirkan pada Service tersebut dan mengisytiharkan CA, nama pelayan, dan sijil klien pilihan; status pengawal adalah isyarat utama bahawa dasar itu berkesan. Saya akan mengehadkan akses Secret dan rentas ruang nama serta mengesahkan sokongan API dan Route bagi pelaksanaan. Service canary akan menguji SAN sijil, amanah CA, putaran, ralat jabat tangan, dan pembinaan semula sambungan. Saya tidak akan sekali-kali menganggap pengesahan yang dinyahdayakan sebagai penyelesaian. Dasar yang tidak sah atau kegagalan sijil harus menyekat trafik yang tidak selamat, memberi amaran, dan mengikut pelan pengunduran.

Kesilapan biasa

Mengkonfigurasi sijil klien-ke-Gateway sahaja dan melupakan permulaan TLS huluan.
Menghalakan targetRef ke objek yang salah atau menganggap setiap pengawal menyokong versi API yang sama.
Mempercayai CA tanpa mengesahkan nama pelayan sijil bahagian belakang.
Menyembunyikan masalah CA, SAN, atau putaran dengan melangkau pengesahan atau berundur ke teks biasa.
Membenarkan pembacaan Secret rentas ruang nama tanpa sempadan kebenaran dan audit.
Menganggap penciptaan sumber yang berjaya sebagai bukti, sambil mengabaikan status, metrik jabat tangan, dan peristiwa pengawal.

Soalan susulan dan jawapan

Bagaimanakah BackendTLSPolicy berkaitan dengan penamatan TLS klien?

Penamatan TLS klien melindungi bahagian pelayar atau pemanggil ke Gateway; BackendTLSPolicy melindungi bahagian Gateway ke Service. Mereka boleh menggunakan sijil dan domain amanah yang berbeza, jadi identiti dan putaran mesti disahkan secara berasingan.

Bagaimana jika nama sijil bahagian belakang tidak sepadan?

Keluarkan sijil bahagian belakang untuk nama pelayan yang digunakan oleh Gateway, atau jadikan nama hos dasar sepadan dengan SAN sijil. Jangan nyahdayakan pengesahan nama; periksa DNS, SNI, penamaan Service, dan rantai sijil.

Bagaimanakah anda melepaskan dasar yang tidak sah?

Sambungkan status tidak sah kepada amaran dan get pelepasan (release gate), hentikan peluasan canary, dan periksa rujukan, bahan CA, kebenaran Secret, dan sokongan pelaksanaan. Teruskan hanya selepas status sah dan jabat tangan lulus; pengunduran kecemasan kembali kepada dasar terakhir yang disahkan.