Istio 中對出口流量的安全控制,第二部分
使用 Istio 出口流量控制來防止涉及出口流量的攻擊。
歡迎來到我們關於 Istio 中出口流量安全控制的新系列的第二部分。在本系列的第一部分中,我介紹了涉及出口流量的攻擊,以及我們針對出口流量安全控制系統收集的需求。在這一期中,我將描述 Istio 安全控制出口流量的方式,並展示 Istio 如何幫助您防止攻擊。
Istio 中出口流量的安全控制
要在 Istio 中實施出口流量的安全控制,您必須將 TLS 流量導向透過出口閘道的外部服務。或者,您可以將 HTTP 流量導向透過出口閘道,並讓出口閘道執行 TLS 來源。
這兩種選擇各有利弊,您應該根據自身情況在它們之間做出選擇。選擇主要取決於您的應用程式是否可以發送未加密的 HTTP 請求,以及您的組織安全策略是否允許發送未加密的 HTTP 請求。例如,如果您的應用程式使用某些用戶端程式庫加密流量,而無法取消加密,您就無法使用發送未加密 HTTP 流量的選項。如果您的組織安全策略不允許在Pod 內部發送未加密的 HTTP 請求(在 Pod 外部,流量由 Istio 加密),情況也是如此。
如果應用程式發送 HTTP 請求,並且出口閘道執行 TLS 來源,您可以監控 HTTP 資訊,例如 HTTP 方法、標頭和 URL 路徑。您也可以根據上述 HTTP 資訊定義策略。如果應用程式執行 TLS 來源,您可以監控 SNI 和來源 Pod 的服務帳戶的 TLS 流量,並根據 SNI 和服務帳戶定義策略。
您必須確保從您的叢集到外部的流量無法繞過出口閘道。Istio 無法為您強制執行此操作,因此您必須應用一些額外的安全機制,例如,Kubernetes 網路策略或 L3 防火牆。請參閱Kubernetes 網路策略設定範例。根據深度防禦概念,您為同一目標應用越多的安全機制,效果就越好。
您還必須確保 Istio 控制平面和出口閘道不會被入侵。雖然您的叢集中可能有數百或數千個應用程式 Pod,但只有十幾個 Istio 控制平面 Pod 和閘道。您可以而且應該專注於保護控制平面 Pod 和閘道,因為這很容易(只有少數 Pod 需要保護),而且對於您的叢集安全至關重要。如果攻擊者入侵控制平面或出口閘道,他們可能會違反任何策略。
根據您的環境,您可能有多種工具來保護控制平面 Pod。合理的安全措施包括:
- 在與應用程式節點分開的節點上執行控制平面 Pod。
- 在它們自己單獨的命名空間中執行控制平面 Pod。
- 應用 Kubernetes RBAC 和網路策略來保護控制平面 Pod。
- 比監控應用程式 Pod 更密切地監控控制平面 Pod。
一旦您將出口流量導向透過出口閘道並應用額外的安全機制,您就可以安全地監控和強制執行流量的安全策略。
下圖顯示了 Istio 的安全架構,並增強了 L3 防火牆,它是額外安全機制的一部分,應在 Istio 外部提供。
您可以輕鬆地將 L3 防火牆配置為僅允許通過 Istio 入口閘道的輸入流量,並且僅允許通過 Istio 出口閘道的輸出流量。閘道的 Istio 代理會像網格中的所有其他代理一樣強制執行策略並報告遙測。
現在讓我們檢查一下可能的攻擊,讓我向您展示 Istio 中出口流量的安全控制如何阻止它們。
防止可能的攻擊
考慮以下出口流量的安全策略
- 應用程式 A 允許存取
*.ibm.com
,其中包括所有 URL 符合*.ibm.com
的外部服務。 - 應用程式 B 允許存取
mongo1.composedb.com
。 - 所有出口流量都會受到監控。
假設攻擊者有以下目標
- 從您的叢集存取
*.ibm.com
。 - 從您的叢集存取
*.ibm.com
,不受監控。攻擊者希望他們的流量不受監控,以防止您檢測到禁止存取。 - 從您的叢集存取
mongo1.composedb.com
。
現在假設攻擊者設法侵入應用程式 A 的其中一個 Pod,並嘗試使用受損的 Pod 執行禁止存取。攻擊者可能會碰碰運氣,並以直接的方式存取外部服務。您將對直接嘗試做出以下反應
- 最初,沒有辦法阻止受損的應用程式 A 存取
*.ibm.com
,因為受損的 Pod 與原始 Pod 沒有區別。 - 幸運的是,您可以監控對外部服務的所有存取,檢測可疑流量,並阻止攻擊者獲得對
*.ibm.com
的不受監控的存取。例如,您可以在出口流量日誌上應用異常檢測工具。 - 為了阻止攻擊者從您的叢集存取
mongo1.composedb.com
,Istio 將正確檢測流量來源,在本例中為應用程式 A,並驗證根據上述安全策略,它不允許存取mongo1.composedb.com
。
在未能以直接方式實現其目標後,惡意行為者可能會訴諸進階攻擊
- 繞過容器的 Sidecar 代理,以便能夠直接存取任何外部服務,而無需 Sidecar 的策略強制執行和報告。Kubernetes 網路策略或 L3 防火牆可阻止此攻擊,這些策略僅允許出口流量從出口閘道離開網格。
- 入侵出口閘道,以便能夠強制其向監控系統發送虛假資訊或禁用安全策略的執行。通過對出口閘道 Pod 應用特殊的安全措施可以防止這種攻擊。
- 模擬為應用程式 B,因為應用程式 B 允許存取
mongo1.composedb.com
。幸運的是,Istio 的強大身分支援可以防止這種攻擊。
就我們所知,所有禁止存取都被阻止,或者至少受到監控,並且可以在以後阻止。如果您看到其他涉及出口流量或目前設計中存在安全漏洞的攻擊,我們很樂意聽到您的意見。
總結
希望我能讓您相信 Istio 是一個有效的工具,可以防止涉及出口流量的攻擊。在本系列的下一部分中,我將比較 Istio 中出口流量的安全控制與其他解決方案,例如Kubernetes 網路策略和舊式出口代理/防火牆。