如何用 Kubernetes Gateway API 設計 TLSRoute 與前端 mTLS？

1. 場景、目標與非目標

平台團隊維護共用 Gateway，業務團隊在各自命名空間部署服務。支付服務要求 Gateway 看不到明文，內部管理服務要求 Gateway 在入口驗證用戶端憑證，稽核團隊要求記錄路由變更和握手失敗。目標是讓團隊能獨立發布路由，同時限制憑證、後端和監聽器的權限。

先聲明非目標：Gateway API 資源只描述意圖，具體 TLS 實作、負載平衡能力和憑證儲存方式仍由 GatewayClass 控制器決定。設計必須包含相容性檢查和控制器能力矩陣，不能把某個實作的行為當成 API 保證。

2. 先拆解 Gateway API 1.5 的能力

Gateway API 1.5 將 TLSRoute、前端用戶端憑證驗證、後端 TLS 相關能力推進到更穩定的階段，並將 ReferenceGrant 提升到 v1。TLSRoute 透過 TLS 握手中的 SNI 比對主機名稱，再把連線轉送到後端；監聽器可選擇 Passthrough 或 Terminate。

Passthrough 讓 Gateway 只代理加密位元組流，後端負責憑證和握手；Terminate 在 Gateway 結束 TLS，再把解密後的 TCP 流送給後端。兩者的金鑰持有者、可見資料、策略執行點完全不同，不能只用「效能」一個指標決定。

3. 設計資源與所有權

基礎設施團隊建立 Gateway 和監聽器，應用團隊建立綁定到監聽器的 TLSRoute。用 parentRefs.sectionName 把路由綁定到明確監聽器，避免一個路由意外接管整個 Gateway。主機名稱、連接埠、協定和憑證引用應在程式碼審查中作為策略輸入。

示例資源表達透傳意圖：

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: 8443

跨命名空間引用必須經過控制器支援的授權機制，並由 ReferenceGrant 或等價策略明確允許；禁止依賴預設可見性。

4. Passthrough 與 Terminate 的取捨

選擇 Passthrough 時，Gateway 不持有私鑰，也看不到應用協定，可以滿足後端直接做雙向 TLS 或嚴格端到端加密的要求。代價是 Gateway 無法按 HTTP 內容路由、統一做應用層限流或在入口驗證用戶端憑證；握手和憑證輪換壓力由後端承擔。

選擇 Terminate 時，Gateway 集中管理憑證並可在入口執行用戶端憑證驗證，路由和觀測更統一。代價是 Gateway 能看到明文，後端鏈路若仍需加密，還要配置後端 TLS；私鑰存取面和控制器故障域也擴大。

面試回答應給出分層方案：支付等高敏感連線預設透傳；需要統一身分與策略的管理服務在 Gateway 終止，並用獨立後端 TLS 保護第二跳。

5. 前端 mTLS 與信任錨

前端 mTLS 的驗證發生在用戶端到 Gateway 的連線上。Gateway 根據配置的 CA 憑證包驗證用戶端憑證；預設的嚴格模式只接受驗證通過的用戶端。若啟用允許不安全回退，缺少或無效憑證的連線仍可能到達後端，必須把它視為明確例外，並配合網路策略和稽核告警。

信任錨應按租戶或環境分組，憑證包透過受控的 Secret/ConfigMap 引用分發。不要讓應用團隊直接引用平台私鑰；輪換時先發布新 CA、觀察雙信任窗口，再撤銷舊 CA，並記錄生效時間與影響範圍。

6. 多租戶授權與衝突處理

共用 Gateway 的監聽器屬於平台邊界，應用只能申請特定主機名稱和後端。控制器應拒絕重疊主機名稱、未授權 parentRefs、跨命名空間後端和不符合連接埠／協定策略的資源，並把拒絕原因寫入資源狀態。

對 ReferenceGrant、Secret 引用和 GatewayClass 能力做准入驗證。策略變更必須經過 Git 審核；執行時只允許控制器根據已批准資源產生配置。發生路由衝突時，寧可保持舊配置並報告 Accepted=False，也不要讓最後寫入者靜默覆蓋其他租戶。

7. 故障、升級與觀測

發布前驗證控制器是否支援 TLSRoute 的穩定版本、所選 TLS 模式、用戶端憑證驗證和後端 TLS。Gateway API 的版本升級可能需要把舊實驗資源遷移到穩定 v1，不能只替換 YAML URL。

觀測至少覆蓋：SNI 比對結果、監聽器和路由狀態、憑證到期時間、用戶端憑證驗證失敗原因、後端連線錯誤、配置分發延遲和每個租戶的握手／流量指標。故障切換時保持憑證信任包、路由狀態和後端健康檢查一致；若 Gateway 不可用，應有 DNS/LB 層的明確回退，而不是把未加密流量直接旁路。

8. 評分要點與追問

必須說清

• 能區分 TLSRoute 的 SNI 路由、Passthrough 與 Terminate 的金鑰和明文邊界。
• 能設計前端 mTLS 的 CA 信任、輪換、失敗策略及跨命名空間授權。
• 能說明控制器能力差異、資源狀態、升級遷移和可觀測性，而不是只貼 YAML。

常見追問

• 同一 SNI 同時被兩個命名空間宣告時，如何避免靜默覆蓋？
• Gateway 終止 TLS 後，如何保證到後端的第二跳仍符合合規加密？
• 用戶端 CA 輪換期間如何支援雙憑證，同時限制舊憑證的最長有效時間？

評分參考

優秀答案會把資源所有權、加密邊界、授權和執行證據連成閉環：先選定誰持有金鑰，再用狀態條件拒絕衝突配置，最後用握手、憑證和後端指標證明策略確實生效。