環境模式安全深度解析

我們最近發布了 Istio 的新環境模式，這是一種用於 Istio 的無 Sidecar 資料平面，也是環境網格模式的參考實作。正如發布部落格中所述，我們透過環境網格解決的首要問題是簡化操作、更廣泛的應用程式相容性、降低基礎設施成本並提高效能。在設計環境資料平面時，我們希望仔細平衡操作、成本和效能方面的考量，同時不犧牲安全性或功能。由於環境網格的元件在應用程式 Pod 之外執行，因此安全邊界已發生變化，我們相信會變得更好。在此部落格中，我們將詳細介紹這些變化以及它們與 Sidecar 部署的比較。

總結一下，Istio 的環境模式引入了一個分層網格資料平面，具有負責傳輸安全和路由的安全疊加層，該疊加層可以為需要它們的命名空間添加 L7 功能。如需了解更多資訊，請參閱發布部落格和入門部落格。安全疊加層由節點共享元件 ztunnel 組成，該元件負責 L4 遙測和 mTLS，並部署為 DaemonSet。網格的 L7 層由航點代理提供，這些是為每個身份/工作負載類型部署的完整 L7 Envoy 代理。此設計的一些核心含義包括

• 將應用程式與資料平面分離
• 安全疊加層的元件類似於 CNI
• 操作的簡化更有利於安全
• 避免多租戶 L7 代理
• Sidecar 仍然是第一級支援的部署

將應用程式與資料平面分離

雖然環境網格的主要目標是簡化服務網格的操作，但它也有助於提高安全性。複雜性會滋生漏洞，而企業應用程式（及其傳遞依賴項、程式庫和框架）非常複雜且容易出現漏洞。從處理複雜的業務邏輯到利用 OSS 程式庫或有錯誤的內部共享程式庫，使用者的應用程式程式碼是攻擊者（內部或外部）的主要目標。如果應用程式遭到入侵，憑證、機密和金鑰將暴露給攻擊者，包括那些掛載或儲存在記憶體中的憑證、機密和金鑰。查看 Sidecar 模型時，應用程式遭到入侵包括接管 Sidecar 和任何相關的身份/金鑰材料。在 Istio 的環境模式中，沒有資料平面元件與應用程式在同一個 Pod 中執行，因此應用程式遭到入侵不會導致存取機密。

那麼，Envoy Proxy 作為潛在的漏洞目標又如何呢？Envoy 是一個經過嚴格審查的極其強化的基礎結構，並且在關鍵環境中大規模執行（例如，在生產環境中用於 Google 網路的前端）。但是，由於 Envoy 是軟體，因此它並非沒有漏洞。當這些漏洞確實出現時，Envoy 具有強大的 CVE 流程，可識別漏洞、快速修復漏洞，並在漏洞有機會造成廣泛影響之前將其推出給客戶。

回到先前「複雜性會滋生漏洞」的評論，Envoy Proxy 最複雜的部分在其 L7 處理中，而且實際上，Envoy 的大多數漏洞都出現在其 L7 處理堆疊中。但是，如果您僅將 Istio 用於 mTLS，該怎麼辦？當您不使用該功能時，為什麼要承擔部署完整的 L7 代理的風險，該代理的 CVE 機會更高？在這裡，分離 L4 和 L7 網格功能就發揮作用了。雖然在 Sidecar 部署中，您會採用所有代理，即使您僅使用一小部分功能，但在環境模式中，我們可以透過提供安全疊加層並僅在需要時加入 L7 來限制暴露。此外，L7 元件完全獨立於應用程式執行，不會提供攻擊途徑。

將 L4 推送到 CNI 中

環境模式資料平面的 L4 元件作為 DaemonSet 執行，或每個節點一個。這表示它是任何在特定節點上執行的 Pod 的共用基礎結構。此元件特別敏感，應與節點上的任何其他共用元件（例如任何 CNI 代理、kube-proxy、kubelet 甚至 Linux 核心）處於相同的層級。來自工作負載的流量會重新導向到 ztunnel，然後 ztunnel 會識別工作負載並選擇正確的憑證，以在 mTLS 連線中表示該工作負載。

ztunnel 會為每個 Pod 使用不同的憑證，而且僅在 Pod 目前在節點上執行時才會發出憑證。這可確保遭到入侵的 ztunnel 的波及範圍僅限於可以竊取目前排程在該節點上的 Pod 的憑證。這與其他良好實作的共用節點基礎結構（包括其他安全 CNI 實作）具有類似的屬性。ztunnel 不使用叢集範圍或每個節點的憑證，如果被竊取，除非也實作了複雜的次要授權機制，否則可能會立即危害叢集中的所有應用程式流量。

如果我們將其與 Sidecar 模型進行比較，我們會注意到 ztunnel 是共用的，並且入侵可能會導致外洩在節點上執行的應用程式的身份。但是，此元件中出現 CVE 的可能性低於 Istio Sidecar，因為攻擊面已大大縮小（僅處理 L4）；ztunnel 不執行任何 L7 處理。此外，Sidecar 中的 CVE（具有更大的 L7 攻擊面）並非真正僅限於受入侵的特定工作負載。Sidecar 中的任何嚴重 CVE 也可能在網格中的任何工作負載中重複發生。

操作的簡化更有利於安全

最終，Istio 是必須維護的關鍵基礎結構。Istio 受信任代表應用程式實作零信任網路安全的一些原則，並按排程或按需推出修補程式至關重要。平台團隊通常具有可預測的修補或維護週期，這與應用程式的週期大不相同。應用程式可能會在需要新功能和功能時進行更新，而且通常是專案的一部分。這種應用程式變更、升級、框架和程式庫修補程式的方法非常難以預測，會允許大量時間流逝，而且不利於安全的安全性實務。因此，將這些安全性功能保留在平台中並與應用程式分開，可能會帶來更好的安全性態勢。

正如我們在發布部落格中所指出的，操作 Sidecar 可能更加複雜，因為它們的侵入性性質（注入 Sidecar/變更部署描述符、重新啟動應用程式、容器之間的競賽條件等）。使用 Sidecar 升級工作負載需要更多規劃和滾動重新啟動，這些重新啟動可能需要協調，以免導致應用程式停機。使用環境模式時，ztunnel 的升級可以與任何正常的節點修補或升級同時進行，而航點代理是網路的一部分，可以根據需要完全透明地升級到應用程式。

避免多租戶 L7 代理

支援 L7 通訊協定，例如 HTTP 1/2/3、gRPC、剖析標頭、實作重試、使用 Wasm 和/或 Lua 在資料平面中進行自訂，比支援 L4 複雜得多。有更多的程式碼可以實作這些行為（包括用於 Lua 和 Wasm 等的使用者自訂程式碼），而且這種複雜性可能會導致出現漏洞的潛在可能性。因此，CVE 在 L7 功能的這些領域中被發現的機會更高。

在環境模式中，我們不會在多個身份的代理中共用 L7 處理。每個身份（Kubernetes 中的服務帳戶）都有自己的專用 L7 代理（航點代理），這與我們使用 Sidecar 的模型非常相似。嘗試將多個身份及其不同的複雜原則和自訂共置在一起，會為共用資源增加很多變化，這充其量會導致成本歸因不公平，最壞的情況會導致代理完全遭到入侵。

Sidecar 仍然是第一級支援的部署

我們了解有些人對 Sidecar 模型及其已知的安全邊界感到滿意，並希望繼續使用該模型。透過 Istio，Sidecar 是網格的第一級公民，平台擁有者可以選擇繼續使用它們。如果平台擁有者想要同時支援 Sidecar 和環境模式，他們可以。具有環境資料平面的工作負載可以與已部署 Sidecar 的工作負載以原生方式通訊。當人們更好地了解環境模式的安全性態勢時，我們相信它將成為 Istio 的首選資料平面模式，Sidecar 用於特定的最佳化。