在現代雲原生環境中，安全與效能的平衡成為企業的核心挑戰。Uber 面對百萬級容器化工作負載、每秒數百萬請求的流量壓力，以及異質化的技術生態系統，亟需一種既能保障安全又不影響性能的解決方案。這正是零信任架構（Zero Trust Architecture, ZTA）的價值所在。本文探討 Uber 如何透過零信任架構實現「Securing Every Bit」，並在 CNCF 生態中整合技術工具以達成目標。
問題與目標
Uber 的現狀面臨三大核心問題：
- 分散的安全措施：部分系統依賴 Kerberos，部分使用自建方案，缺乏中央稽核機制。
- 缺乏統一標準：加密與授權策略依服務關鍵性而異，導致安全層級不一致。
- 性能與可用性壓力：服務所有者對吞吐量、延遲與 SLA 有嚴格要求，任何安全措施若影響效能將直接影響業務。
目標是建立零信任架構，確保所有工作負載（服務、資料庫、批次作業等）之間的加密、驗證、授權與稽核，並在不影響性能的前提下實現全面覆蓋。
技術解決方案：三個核心原則
1. 最低公分母（Minimum Common Denominator）
Uber 選擇以 TCP 協議為基礎，目標為連線層級加密與授權，而非請求層級。此設計參考 ISTIO 與 ZTunnel 的基層經驗，重用現有工具如 Envoy 與 Spire，以降低開發成本並提升可靠性。
2. 重用現有工具（Leverage Existing Tools）
- Envoy 作為資料平面核心：整合現有 L7 代理層遷移經驗，處理 MTLS、Proxy Protocol 與動態轉發，並透過自訂插件擴展功能。
- Spire 管理憑證：結合容器身份驗證（如多編排器環境下的容器標籤），確保憑證的動態更新與驗證。
3. 漸進式降級（Progressive Rollback）
部署時若遇問題，可自動回滾至原有狀態，確保服務可用性。此策略在 2023 年底至 2024 年初的 POC 階段已驗證其有效性。
技術實現與性能優化
資料平面架構
- Linux 內核技術整合：使用 NFTables 與 eBPF 將流量重定向至 Envoy 代理，實現細粒度控制。
- 容器管理：包裝 runC 以注入容器啟動時的驗證與配置檢查，確保主機環境正確。容器啟動時更新 Envoy 的憑證與策略配置，確保連線建立前完成設定。
- 通訊協議選擇：採用一對一 TCP 連線，於其上使用 MTLS 與 Proxy Protocol 傳遞原始目的地資訊。避用 H2 Connect 因穩定性與效能問題，選擇 TCP 直接連線以減少頭阻塞風險。
效能挑戰與解決方案
- Envoy 架構與事件循環：主線程處理控制平面（如健康檢查、指標），工人線程管理數據平面（連接生命週期）。使用「shared nothing」架構，每個工人線程擁有獨立的監聽器、連接集，避免資源共享。
- TLS 連接瓶頸：TLS 握手過程為 CPU 密集型，平均耗時 1 毫秒，導致高連接數時延遲增加。透過自適應隊列與分發（Adaptive Queuing & Dispatching）限制每個事件循環接受的連接數，並根據機器負載動態調整處理順序（FIFO → LIFO），提升連接建立成功率。
- 會話重用：透過 TLS 通訊中緩存上游端點的會話密鑰，會話重用率提升至 30% 以上，每秒處理 400,000 個連接。
當前狀態與未來目標
- 上線進度：無狀態服務與有狀態服務已全面上線，僅剩少數例外案例待處理。批次作業約完成 50% 上線，其他框架與生態系統逐步整合。
- 流量統計：億級連接數、每秒數百萬新連接，40% 網路流量透過平臺處理，60% 來自批次作業。
- 未來目標：完善 QoS 功能（如批次流量優先級調整），並持續優化效能與可靠性。
結論
Uber 的零信任架構實踐體現了在規模化環境中平衡安全與效能的關鍵策略。透過 Envoy、Spire 等 CNCF 生態工具的整合，以及漸進式部署與性能優化，成功實現了「Securing Every Bit」的目標。未來，隨著量子密碼算法的評估與加密標準的升級，零信任架構的持續演進將是企業安全的必然選擇。