Trusted Proxy Hardening

概念概覽

兩種設計的本質區別

核心知識

兩種設計的本質區別

Assumption-based（脆弱）：靠 trustedProxyCount 從 XFF header 反推第 N 個 IP 當作 client IP，但不驗證直連來源是否真的是受信 proxy。如果攻擊者能直連繞過 ingress，XFF 可被偽造。

Closed-loop（真正 hardened）：app 層額外驗證直連 TCP source IP 是否在 trusted proxy CIDR 清單內，再取 XFF。即使 ingress 配置有誤，app 層還有一道防線（defense-in-depth）。

IP Whitelist 空值退化陷阱

base ConfigMap: ALLOWED_IPS=""
overlays: 沒有覆蓋這個值
server 邏輯: whitelist 為空 → 退化為 no-op（全放行）

這種「空值 = 全放行」的 fallback 設計，讓文件宣稱「IP whitelist 已啟用」的 feature 實際上完全無保護。

推薦演進路徑

1. 短期：確保 overlay 正確填入非空 IP 清單，修復退化
2. 中期：app 層補 trusted proxy CIDR 驗證，不依賴「假設 ingress 正確」
3. 長期：考慮 mTLS 或 service mesh 替代 IP-based trust

經驗教訓

• 「infra 有保護」和「app 層驗證了」是兩件事，都需要才算 hardened

• 空值退化成全放行是安全設計的常見反模式，需要明確的 fail-closed 語義

• 文件宣稱 done 不等於真的 done，要對照 repo + live cluster 三方驗收

常見陷阱

• 只依賴 trustedProxyCount，沒有驗證直連來源是否真的是受信 proxy

• whitelist 空字串被當成「不限制」而非「設定錯誤」

• server 和 infra 兩邊各自宣稱完成，但沒有交叉驗證

最佳實踐

• IP whitelist 為空時應 fail-closed（拒絕所有）而非 fail-open（全放行）

• trusted proxy 設計應 defense-in-depth：ingress 層 + app 層雙重驗證

• 每個 security feature 需要 server + infra 雙邊都對齊才算交付

相關概念

• Istio Cross-Namespace xDS Authentication
• Istio Header-Based Environment Routing

來源 Sessions

日期	Session	貢獻摘要

| 2026-03-30 | de4cc14f-f3ed-4243-b84e-6062bb47c079 | 提出 assumption-based vs closed-loop 的 trusted proxy 設計分類，明確指出只靠 trustedProxyCount 計數是脆弱假設而非真正 hardened |

---

本概念頁面由 Semi-Brain Wiki 系統自動維護

最後更新: 2026-03-30