Istio 中安全控制出口流量，第 3 部分
比較控制出口流量的替代解決方案，包括效能考量。
歡迎來到我們關於在 Istio 中安全控制出口流量系列的第 3 部分。在本系列的第一部分中，我介紹了涉及出口流量的攻擊，以及我們為出口流量安全控制系統收集的要求。在本系列的第二部分中，我介紹了 Istio 保護出口流量的方式，並展示了如何使用 Istio 來防止攻擊。
在這一部分中，我將比較在 Istio 中安全控制出口流量與其他替代解決方案，例如使用 Kubernetes 網路政策和傳統出口代理和防火牆。最後，我將描述關於在 Istio 中安全控制出口流量的效能考量。
出口流量控制的替代解決方案
首先，讓我們回顧一下我們之前收集的出口流量控制要求
- 支援具備 SNI 的 TLS，或支援 TLS 發起。
- 監控每個出口存取的 SNI 和來源工作負載。
- 定義和實施每個叢集的原則。
- 定義和實施每個來源的原則，具 Kubernetes 感知能力。
- 防止竄改.
- 流量控制對應用程式是透明的。
接下來，我將介紹出口流量控制的兩種替代解決方案：Kubernetes 網路政策和出口代理及防火牆。我將展示它們滿足的要求，更重要的是，它們無法滿足的要求。
Kubernetes 提供了一個用於流量控制的原生解決方案，尤其是用於透過網路政策控制出口流量。使用這些網路政策，叢集運營商可以設定哪些 Pod 可以存取特定的外部服務。叢集運營商可以透過 Pod 標籤、命名空間標籤或 IP 範圍來識別 Pod。若要指定外部服務，叢集運營商可以使用 IP 範圍，但不能使用網域名稱，例如 cnn.com。這是因為 Kubernetes 網路政策不具備 DNS 感知能力。網路政策滿足第一個要求，因為它們可以控制任何 TCP 流量。網路政策僅部分滿足第三和第四個要求，因為叢集運營商可以指定每個叢集或每個 Pod 的政策，但運營商無法透過網域名稱來識別外部服務。如果攻擊者無法從惡意容器中入侵 Kubernetes 節點並干擾節點內政策的實施，則網路政策僅滿足第五個要求。最後，網路政策確實滿足第六個要求：運營商不需要變更程式碼或容器環境。總之，我們可以說 Kubernetes 網路政策提供了透明、具備 Kubernetes 感知能力的出口流量控制，但它不具備 DNS 感知能力。
第二個替代方案早於 Kubernetes 網路政策。使用具備 DNS 感知能力的出口代理或防火牆，您可以設定應用程式將流量導向代理，並使用某些代理協定，例如 SOCKS。由於運營商必須設定應用程式，因此此解決方案不透明。此外，運營商無法使用 Pod 標籤或 Pod 服務帳戶來設定代理，因為出口代理不了解它們。因此，出口代理不具備 Kubernetes 感知能力，並且無法滿足第四個要求，因為如果 Kubernetes 成品指定來源，則出口代理無法依來源強制執行政策。總之，出口代理可以滿足第一、第二、第三和第五個要求，但無法滿足第四和第六個要求，因為它們不透明且不具備 Kubernetes 感知能力。
Istio 出口流量控制的優點
Istio 出口流量控制具備 DNS 感知能力：您可以根據 URL 或萬用字元網域 (例如 *.ibm.com) 定義原則。從這個意義上來說，它優於不具備 DNS 感知能力的 Kubernetes 網路政策。
Istio 出口流量控制在 TLS 流量方面是透明的，因為 Istio 是透明的：您無需變更應用程式或設定其容器。對於具備 TLS 發起的 HTTP 流量，您必須設定網格中的應用程式以使用 HTTP 而非 HTTPS。
Istio 出口流量控制具備 Kubernetes 感知能力：出口流量來源的身分依據 Kubernetes 服務帳戶。Istio 出口流量控制優於不透明且不具備 Kubernetes 感知能力的傳統 DNS 感知代理或防火牆。
Istio 出口流量控制是安全的：它基於 Istio 的強大身分，並且當您套用額外的安全措施時，Istio 的流量控制具有防止竄改的能力。
此外，Istio 的出口流量控制還提供以下優勢
- 以相同的語言定義入口、出口和叢集內流量的存取原則。您只需要學習一種適用於所有類型流量的原則和設定語言。
- Istio 的出口流量控制與 Istio 的原則和可觀察性轉接器開箱即用整合。
- 僅使用 Istio 編寫轉接器一次，即可將它們用於所有類型的流量：入口、出口和叢集內流量，以使用外部監控或存取控制系統。
- 將 Istio 的流量管理功能用於出口流量：負載平衡、被動和主動健康檢查、斷路器、逾時、重試、故障注入等。
我們將具有上述優勢的系統稱為具備 Istio 感知能力。
下表總結了 Istio 和替代解決方案提供的出口流量控制功能
| Istio 出口流量控制 | Kubernetes 網路政策 | 傳統出口代理或防火牆 | |
|---|---|---|---|
| 具備 DNS 感知能力 | |||
| 具備 Kubernetes 感知能力 | |||
| 透明 | |||
| 具備 Istio 感知能力 |
效能考量
使用 Istio 控制出口流量的代價是：呼叫外部服務的延遲增加，以及叢集 Pod 的 CPU 使用率增加。流量會通過兩個代理
- 應用程式的 Sidecar 代理
- 出口閘道的代理
如果您使用到萬用字元網域的 TLS 出口流量，則必須在應用程式和外部服務之間新增額外的代理。由於出口閘道的代理和使用萬用字元設定任意網域所需的代理之間的流量位於 Pod 的本機網路上，因此該流量不應對延遲產生重大影響。
請參閱針對設定為控制出口流量的不同 Istio 設定的效能評估。我建議您在使用自己的應用程式和自己的外部服務仔細測量不同的設定，然後再決定是否可以接受您的使用案例的效能負擔。您應該權衡所需的安全級別與您的效能要求，並比較所有替代解決方案的效能負擔。
讓我分享一下我對使用 Istio 控制出口流量所增加的效能負擔的想法：存取外部服務的延遲可能已經很高，並且相較之下，叢集內兩個或三個代理所增加的負擔可能不會非常顯著。畢竟，具有微服務架構的應用程式在微服務之間可能會有數十個呼叫鏈。因此，在出口閘道中多一個或兩個代理的額外躍點應該不會有很大的影響。
此外，我們將繼續努力減少 Istio 的效能負擔。可能的最佳化包括
- 擴充 Envoy 以處理萬用字元網域：這將消除在應用程式和外部服務之間為該使用案例新增第三個代理的需求。
- 僅針對驗證使用相互 TLS，而不加密 TLS 流量，因為流量已加密。
摘要
我希望在閱讀本系列文章後，您確信控制出口流量對於叢集的安全性非常重要。希望我也成功說服您，Istio 是一種有效且安全地控制出口流量的工具，並且 Istio 比其他替代解決方案具有多種優勢。據我所知，Istio 是唯一可以讓您
- 以安全且透明的方式控制出口流量
- 將外部服務指定為網域名稱
- 使用 Kubernetes 成品來指定流量來源
我認為，如果您正在尋找您的第一個 Istio 使用案例，安全控制出口流量是一個絕佳選擇。在這種情況下，Istio 已經在您開始使用所有其他 Istio 功能之前為您提供了一些好處：流量管理、安全性、原則和 可觀察性，套用於叢集內部微服務之間的流量。
因此，如果您還沒有機會使用 Istio，請在您的叢集上安裝 Istio，並查看我們的出口流量控制任務和其他Istio 功能任務。我們也想聽聽您的意見，請加入我們的 discuss.istio.io。
