如何實現安全的服務網格

如何實現安全的服務網格

目前，我正在嘗試將我們所有的工作負載整合到所謂的服務網格下。服務網格是位於所有集群中每個 pod 之間的網絡層。我們可以使用網格及其相關工具將一組 pod 帶入一個單獨定義且安全的網絡數據平面。

為了寫這篇文章，我將介紹隈研吾。 Kuma 是基於 Envoy 構建的開源解決方案，充當微服務和服務網格的控制平面。它兼容 Kubernetes 和虛擬機，並且可以支持集群中的多個網格。
還有其他開源和託管服務網格可供選擇，例如 
為什麼要使用服務網格？
我們使用服務網格的主要原因之一是在內部 pod 服務之間獲得相互傳輸層安全性 (mTLS) 以確保安全。此外，使用服務網格有很多好處，因為它允許跨多個 Kubernetes 集群鏈接工作負載，或者運行連接到 Kubernetes 的標準裸機應用程序。它提供 pod 之間連接的跟踪和日誌記錄，並且可以將連接端點健康指標輸出到 Prometheus。

此圖顯示了在實施服務網格之前工作負載的樣子。在左側的示例中，團隊花費時間構建管道而不是構建產品或服務，通用功能跨服務複製，存在不一致的安全性和可觀察性實踐，並且存在不可見的黑盒實現。

在右側，在實施服務網格後，同一個團隊可以構建產品和服務。他們能夠構建可擴展且高效的分佈式架構，其中可觀察性在多個平台上保持一致，從而更容易實施安全性和合規性最佳實踐。
Kuma 服務網格架構的工作原理
將應用程序 pod 的套接字通信從純文本轉移到 mTLS 的神奇之處在於 Kuma 控制平面、邊車和 Kuma 容器網絡接口 (CNI)。當開發人員合併一些更改、向應用程序添加新服務時，Kuma 會透明地檢測並註入所需的位，以自動代理跨其自己的網絡數據平面的流量。

Kuma 服務網格由三個組件組成：

Kuma CNI：這個 CNI 插件可以根據註釋識別帶有 sidecar 的用戶應用程序 pod，以設置流量重定向。它在 pod 生命週期的網絡設置階段執行此操作，此時每個 pod 通過稱為 mutating webhook 的過程在 Kubernetes 中調度。
Kuma-sidecar：它運行在公開服務的每個實例上。這些服務將所有連接性和可觀察性問題委託給將在每個請求的執行路徑上的進程外運行時環境。它代理所有出站連接並接受所有入站連接。當然，它還在運行時強制執行流量策略，例如路由或日誌記錄。使用這種方法，開發人員不必擔心加密連接，可以完全專注於服務和應用程序。它被稱為 sidecar 代理，因為它是在同一個 pod 上與服務進程一起運行的另一個容器。每個正在運行的服務實例都會有一個 sidecar 代理實例；再次因為所有傳入和傳出的請求及其數據總是通過 sidecar 代理傳輸，這也稱為 Kuma 數據平面（DP），因為它位於網絡數據路徑上。
Kuma 控制平面 (kuma-cp)：這是一個用 GoLang 編寫的分佈式可執行文件，可以在 Kubernetes 上運行，頒發數據平面證書，並在 Kubernetes API 內協調數據平面 (DP) 狀態。您可以使用 Kuma 自定義資源定義 (CRD) 來配置 Kuma 設置和策略，並且 Sidecar 會自動從控制平面獲取更改。
結語
今天的服務網格拓撲與 1990 年代和 2000 年代的企業服務總線 (ESB) 架構非常相似。無需像 ESB 架構那樣根據業務策略沿路由引導代理流量，使用網格，您可以自由連接應用程序，並且網格自上而下管理路由和策略。

在我看來，ESB 架構在業界不受歡迎的最大原因是它必須滿足單體代碼庫的需求以及最終經常遇到的依賴管理問題。您有數十個項目共享依賴項來管理 ESB 上的對象，這成為軟件管理的一大難題。

服務網格技術通過將其與代碼分開來降低複雜性。它允許開發人員將安全性、可靠性和可觀察性的複雜性作為基礎設施環境的一部分從應用程序堆棧中移出。

原標題：​​​Implementing a Secure Service Mesh​​​，作者：Jonathan Kelley