引言
在雲原生架構中，Kubernetes已成為容器編排的標準化平臺，但其內建的網路策略機制仍面臨安全挑戰。隨著DDoS攻擊與持續性威脅行為者的威脅升級，傳統依賴邊界防禦的授權策略已無法有效應對內部威脅（如離職員工或混淆副手攻擊）。本文探討如何透過標準化身分管理與基於身分的授權策略，建立更強化的安全防禦體系，並分析現有解決方案的優勢與挑戰。
標準化身分與授權策略
技術定義與核心概念
Kubernetes系統需建立基於身分的授權策略，以強化內部服務間（east-west）的存取控制。傳統NetworkPolicy v1機制存在隱式拒絕、IP層面身分辨識、可擴展性與一致性問題等限制，無法直接綁定服務帳號（ServiceAccount）等身份。零信任（Zero Trust）哲學強調不預設信任，透過層層防禦機制降低風險。
關鍵特性與功能
- 身份綁定：服務帳號取代標籤選擇器，策略僅於入口（Ingress）執行，非出口（Egress）。
- 多層級策略整合：支援L3/L4/L7層策略協同執行，例如TLS握手資訊（如MTLS證書）與HTTP標頭的結合。
- 集群級管理：提供Cluster Scope與Namespace Scope策略，確保高優先順序的集群級策略。
- 加密與驗證協調：整合路由策略與加密需求，例如Selium網路策略中要求加密的條件。
實際應用案例
- Psyllium：透過標籤選擇器定義身分，支援進出流量控制，但缺乏對服務帳號的直接綁定。
- Pod Identity：一對一綁定服務帳號，僅支援進流量控制，無出流量策略。
- Cublet標準化：探討Cublet作為身份發行者的可行性，解決身份分散與L4 CNI組件協調問題。
優勢與挑戰
優勢：
- 提升內部威脅防禦能力，降低誤判風險。
- 支援多種身份類型（如JWT、X.509憑證），適應混合雲與跨雲端環境。
- 透過CNCF推動標準化，促進工具生態整合。
挑戰：
- 不同實現間缺乏標準化，跨工具整合困難。
- 身分傳輸與解析機制不統一，影響策略執行一致性。
- 網路層策略組合（如L3/L4/L7）需明確責任分界，避免執行順序矛盾。
網路層策略整合
層級分類與整合問題
- L3/L4層：IP位址、埠、協議。
- L4 TLS層：TLS握手資訊（如MTLS證書）。
- L7層：HTTP標頭、請求體。
現有實現將不同層級屬性合併至同一CRD，導致語義混亂。當策略包含L7屬性但流量為L3/L4時，部分實現忽略L7屬性或預設拒絕，造成策略執行點分散，用戶難以追蹤拒絕原因。
策略組合與執行問題
- 組合挑戰：不同層級策略（L3/L4/L7）需協同執行，例如TLS身份驗證需在IP連線完成後進行，導致執行順序矛盾。
- 未來方向：探討CNCF網路類別（Network Class）概念，明確各組件責任，並分離不同層級策略資源（Network Policy API vs. App Policy API）。
技術挑戰與未來路線
組合問題（Composition Problem）
- 如何讓不同層級策略（CNI、Mesh）協同執行？例如加密流量需與路由策略整合。
- 需明確各層級責任，例如L3/L4由CNI處理，L7由Mesh處理。
標準化建議
- 探討API設計（如Gateway API或Network Policy API）的整合方式。
- 參考Psyllium等項目經驗，學習如何在API中表達加密需求。
- 考慮UDP/TLS組合可行性，因TLS通常基於TCP。
結論
標準化身分管理需明確範疇（Pod、VM、主機等）、策略層級整合、加密與驗證協調。未來需啟動工作流討論，朝向CNCF標準化，並探討Cublet等技術的應用。透過統一身份與策略API設計，可有效應對持續威脅行為者與DDoS攻擊等安全需求。