Istio 中對出口流量的安全控制，第一部分

涉及出口流量的攻擊以及對出口流量控制的要求。

2019 年 5 月 22 日 | 作者：Vadim Eisenberg - IBM

這是關於 Istio 中出口流量安全控制的新系列文章的第一部分，我將會陸續發表。在這篇文章中，我將解釋為什麼您應該對您的叢集應用出口流量控制、您想要阻止的涉及出口流量的攻擊，以及出口流量控制系統為此所需的要求。一旦您同意應該控制來自您叢集的出口流量，就會出現以下問題：出口流量安全控制系統需要什麼？滿足這些要求的最佳解決方案是什麼？（劇透：我認為是 Istio）未來的文章將描述Istio 中出口流量安全控制的實作，並將其與其他解決方案進行比較。

對於服務網格而言，最重要的安全面向可能是入口流量。您絕對必須防止攻擊者通過入口 API 滲透到叢集。話雖如此，保護離開網格的流量也非常重要。一旦您的叢集被入侵（您必須為這種情況做好準備），您需要盡可能減少損害，並防止攻擊者使用該叢集對外部服務和叢集外部的舊系統進行進一步的攻擊。為了實現該目標，您需要對出口流量進行安全控制。

合規性要求是實施出口流量安全控制的另一個原因。例如，《支付卡產業 (PCI) 資料安全標準》要求進出流量必須限制在必要的範圍內

特別是關於出口流量

讓我們從涉及出口流量的攻擊開始。

攻擊

如果 IT 組織尚未遭受攻擊，則必須假設它將會遭受攻擊，並且其基礎架構的一部分可能已經或將來會受到損害。一旦攻擊者能夠滲透到叢集中的應用程式，他們就可以繼續攻擊外部服務：舊系統、外部網路服務和資料庫。攻擊者可能想要竊取應用程式的資料並將其傳輸到他們的外部伺服器。攻擊者的惡意軟體可能需要存取攻擊者的伺服器才能下載更新。攻擊者可能會使用叢集中的 Pod 來執行 DDOS 攻擊或入侵外部系統。即使您無法知道所有可能的攻擊類型，您也希望減少任何攻擊的可能性，無論是已知的還是未知的。

外部攻擊者通過應用程式中的錯誤從網格外部獲得對應用程式容器的存取權，但攻擊者也可能是內部的，例如，組織內部的惡意 DevOps 人員。

為了防止上述攻擊，必須應用某種形式的出口流量控制。讓我在下一節中介紹出口流量控制。

解決方案：出口流量的安全控制

出口流量的安全控制意味著監控出口流量並強制執行所有關於出口流量的安全策略。監控出口流量使您可以分析它（可能離線），並檢測攻擊，即使您無法即時阻止它們。另一個減少攻擊可能性的好方法是指定限制存取的策略，並遵循需要知道的原則：只有需要外部服務的應用程式才應被允許存取它們需要的外部服務。

現在讓我轉向我們收集的出口流量控制要求。

出口流量控制的要求

我在 IBM 的同事和我從多個客戶那裡收集了對出口流量安全控制的要求，並將它們與來自 Kubernetes 網路特殊興趣小組的出口流量控制要求結合在一起。

Istio 1.1 滿足所有收集到的要求

  1. 支援具有SNI的TLS，或由 Istio 進行TLS 發起。

  2. 監控 SNI 和每個出口存取的來源工作負載。

  3. 定義並強制執行每個叢集的策略，例如

    • 叢集中的所有應用程式都可以存取 service1.foo.com（特定主機）

    • 叢集中的所有應用程式都可以存取任何形式為 *.bar.com 的主機（萬用字元網域）

    必須封鎖所有未指定的存取。

  4. 定義並強制執行每個來源的策略，感知 Kubernetes

    • 應用程式 A 可以存取 *.foo.com。

    • 應用程式 B 可以存取 *.bar.com。

    必須封鎖所有其他存取，特別是應用程式 A 對 service1.bar.com 的存取。

  5. 防止篡改。如果應用程式 Pod 受到損害，請防止受損的 Pod 逃避監控、向監控系統傳送虛假資訊以及破壞出口策略。

  6. 理想情況：流量控制對應用程式是透明的。

讓我更詳細地解釋每個要求。第一個要求指出，必須僅支援對外部服務的 TLS 流量。此要求是在觀察到所有離開叢集的流量都必須加密後出現的。這意味著應用程式執行 TLS 發起或 Istio 必須為它們執行 TLS 發起。請注意，在應用程式執行 TLS 發起的情況下，Istio 代理看不到原始流量，只能看到加密的流量，因此代理只能看到 TLS 協定。對於代理來說，原始協定是 HTTP 還是 MongoDB 並不重要，所有 Istio 代理看到的都是 TLS 流量。

第二個要求指出，必須監控 SNI 和流量的來源。監控是防止攻擊的第一步。即使攻擊者能夠從叢集存取外部服務，如果存取受到監控，也有機會發現可疑流量並採取糾正措施。

請注意，在應用程式發起 TLS 的情況下，Istio Sidecar 代理只能看到 TCP 流量和包含 SNI 的 TLS 交握。來源 Pod 的標籤可以識別流量的來源，但可以使用 Pod 的服務帳戶或其他來源識別符。我們將出口控制系統的此屬性稱為感知 Kubernetes：系統必須了解 Kubernetes 的成品，如 Pod 和服務帳戶。如果系統不感知 Kubernetes，它只能將 IP 位址監控為來源的識別符。

第三個要求指出，Istio 運算子必須能夠為整個叢集的出口流量定義策略。這些策略說明叢集中的任何 Pod 可以存取哪些外部服務。外部服務可以通過服務的完整網域名稱（例如 www.ibm.com）或通過萬用字元網域（例如 *.ibm.com）來識別。只能存取指定的外部服務，所有其他出口流量都被封鎖。

此要求源於需要阻止攻擊者存取惡意網站，例如下載惡意軟體的更新/指示。您還想限制攻擊者可以存取和攻擊的外部網站數量。您只想允許存取叢集中應用程式需要存取的外部服務，並阻止存取所有其他服務，這樣您就可以減少攻擊面。雖然外部服務可以擁有自己的安全機制，但您想執行縱深防禦並擁有多個安全層：除了外部系統中的安全層之外，叢集中還有一個安全層。

此要求表示外部服務必須可通過網域名稱識別。我們將出口控制系統的此屬性稱為感知 DNS。如果系統不感知 DNS，則必須通過 IP 位址指定外部服務。使用 IP 位址不方便且通常不可行，因為服務的 IP 位址可能會更改。有時甚至不知道服務的所有 IP 位址，例如在CDN的情況下。

第四個要求指出，必須將出口流量的來源新增到策略中，從而有效地擴展第三個要求。策略可以指定哪個來源可以存取哪個外部服務，並且必須像第二個要求一樣識別來源，例如通過來源 Pod 的標籤或 Pod 的服務帳戶。這意味著策略強制執行也必須感知 Kubernetes。如果策略強制執行不感知 Kubernetes，則策略必須通過 Pod 的 IP 識別流量的來源，這很不方便，尤其是因為 Pod 可以來來去去，因此它們的 IP 不是靜態的。

第五個要求指出，即使叢集受到損害並且攻擊者控制了一些 Pod，他們也絕不能欺騙監控或違反出口控制系統的策略。我們說這樣的系統提供對出口流量的安全控制。

第六個要求指出，應在不變更應用程式容器的情況下提供流量控制，特別是在不變更應用程式程式碼且不變更容器環境的情況下。我們將這種出口流量控制稱為透明。

在下一篇文章中，我將展示 Istio 如何作為滿足所有這些要求的出口流量控制系統範例，特別是它是透明的、感知 DNS 和感知 Kubernetes 的。

總結

我希望您確信控制出口流量對於您叢集的安全性至關重要。在本系列的第二部分中，我描述了 Istio 執行安全控制出口流量的方法。在本系列的第三部分中，我將其與替代解決方案進行比較，例如Kubernetes 網路政策和傳統的出口代理/防火牆。

分享這篇文章