服務網格是一項熱門技術，有時甚至被吹捧為微服務成功的必要條件。但是，與許多抽象一樣，服務網格可以節省時間，但不會節省學習時間。事實上，許多小型平臺團隊對服務網格增加的復雜性感到不知所措，尤其是在涉及到長時間的操作時。

很自然地會問一個問題：額外的復雜性真的超過了好處嗎？

在這篇文章中，我們提出了在投資服務網格之前要考慮的替代方案。服務網格最流行的好處是：

• 驗證;
• 入口加密；
• 集群內網絡加密；
• 通訊隔離。

對于這些好處中的每一個，我們將展示根據我們的經驗更接近管理員已經熟悉的替代方案。對于專業知識或平臺工程帶寬稀缺的組織，這些可能更具吸引力。

在某些情況下，您將需要服務網格，例如當您需要跨多個 Kubernetes 集群的安全 Pod 到 Pod 通信時。通過排除不能滿足您需求的解決方案，您將進一步說服自己為什么選擇服務網格開始。

Service Mesh 優勢 1 - 使用 OAuth2-proxy 進行身份驗證

許多應用程序團隊需要在他們的微服務前面添加一個身份驗證層。例如，完全實現 OAuth2 或 OpenID 涉及相當多的跳轉。與其編寫大量樣板代碼（這與應用程序非特定和非業務差異化相比），團隊更愿意“某物”只是將具有正確聲明的 JWT 令牌交給他們的應用程序，以便專注于特定于應用程序的訪問控制。

我們之前寫過關于如何將 Istio 與 OAuth2-proxy 集成以實現這一目標的博客。但是，如果這是您從 Istio 中唯一需要的東西，那么采用它可能有點過頭了。

服務網格的替代方案：Nginx Ingress Controller

讓我舉例說明一個我認為更簡單的解決方案，尤其是對于已經使用 Nginx 的團隊。如果你只需要一些好的 oauth2-proxy，Nginx Ingress Controller 很容易與之集成。只需使用 auth-url 注釋，控制器將完成其余的工作。下圖說明了這是如何工作的。

我認為這個解決方案更簡單的原因是它只會影響流量進入 Kubernetes 集群的方式。Pod 到 Pod 的通信和以前一樣工作。

如果您熟悉 Nginx，但害怕 Ingress Controller 在其周圍添加的自動化，您可以通過鍵入以下內容直接檢查 Nginx 的配置方式：

kubectl exec -ti \
-n ingress-nginx \
$(kubectl get pod \
-n ingress-nginx \
-l app.kubernetes.io/component=controller \
-o name \
| head -1 \
) \
-- \
cat /etc/nginx/nginx.conf

默認情況下，您的應用程序不會獲得 JWT 令牌。為了確保您的應用程序獲得細粒度訪問控制的聲明，您必須做兩件事：

• 首先，將--set-authorization-header命令行選項添加到 oauth2-proxy：這可確保 oauth2-proxy 生成 HTTP 授權標頭。
• 其次，將以下注釋添加到您的 Ingress：nginx.ingress.kubernetes.io/auth-response-headers: “authorization” 。這可確保 Nginx 入口控制器將 HTTP 授權標頭從 oauth2-proxy 轉發到您的應用程序。

如果您需要更多詳細信息，可以在此處找到現成的代碼片段。

• ?https://github.com/elastisys/compliantkubernetes/blob/main/user-demo/deploy/oauth2-proxy.yaml
• https://elastisys.io/compliantkubernetes/user-guide/network-model/#ingress?

Service Mesh 優勢二：入口加密

許多法規要求對不受信任網絡上的網絡流量進行加密。例如，PCI-DSS 要求 4 規定：“通過在開放的公共網絡上加密來傳輸持卡人數據。” GDPR 和瑞典醫療保健（“Behandling av personuppgifter i?ppna n?t”“通過開放網絡處理個人數據”）包含類似規定。

解決方案很簡單：添加 TLS 終止。但是，TLS 終止不是業務差異化，也不是特定于應用程序的。理想情況下，平臺應該“做它”。我經常看到團隊僅針對這一功能采用服務網格，但還有一種更簡單的替代方案。

服務網格的替代品：Cert-manager

您可以安裝cert-manager，創建 ClusterIssuer 并通過注解使用該 ClusterIssuer 配置您的 Ingress。Cert-manager 將發揮與 LetsEncrypt 對話的魔力，提供 TLS 證書并在其到期前輪換它。

這在上圖和相同的即用型代碼片段中進行了說明。請參閱cert-manager.io/cluster-issuer注釋。

Service Mesh 優勢三：集群內網絡加密

為一些爭議做好準備。

我經常看到組織添加服務網格，因為 mTLS 和 Pod 到 Pod 加密很酷，并且可能是某些法規要求的。這是我對這個話題的看法。

首先，您很少（如果有的話）需要 Pod 到 Pod 加密。如上所述，PCI-DSS 和瑞典醫療保健都只需要對開放（即不受信任）網絡進行加密。我經常聽到團隊爭論 Pod 到 Pod 加密“以防萬一”底層網絡不受信任。如果您不能信任您的基礎設施提供商，請更換提供商。再多的加密都不會阻止他們在內存中未加密時訪問您的數據。

其次，假設您確實需要集群內加密。例如，您希望將 Kubernetes 集群擴展到通過不受信任的網絡連接的兩個數據中心。或者，您希望避免與兩個數據中心之間的網絡提供商簽署另一個 GDPR 風格的數據保護協議 (DPA)。

服務網格的替代方案：CNI 級加密

在這種情況下，只需在您的容器網絡接口 (CNI) 提供程序中啟用 WireGuard 或 IPsec。這樣就達到了加密網絡流量Node-to-Node的效果。至少Calico和Flannel對此有支持。例如，如果您使用 Kubespray 設置 Calico，只需添加：

calico_wireguard_enabled: true

Service Mesh 的優勢四：網絡通信的隔離

服務網格帶來了另一個特性：它們為每個 Pod 賦予一個身份，然后通過相互身份驗證 (mTLS) 實施基于身份的訪問控制。這帶來了兩個好處：首先，您的 Pod “不要與陌生人交談”，這有助于使某些漏洞更難被利用，例如臭名昭著的Log4Shell。其次，它減少了爆炸半徑：如果 Pod 被闖入，攻擊者會發現很難橫向移動。

服務網格的替代方案：NetworkPolicies

但是使用 NetworkPolicies 可以更簡單、更標準化地實現相同的好處。它們就像容器化世界中的防火墻規則或安全組。由于 Pod 在每次部署時都會更改 IP 地址，因此 NetworkPolicies 本質上會將 Pod 身份轉換為基于 IP 的防火墻規則，由 Linux 內核強制執行。

NetworkPolicy 由兩部分組成：選擇器和規則。選擇器選擇 NetworkPolicy 應用于哪些 Pod，匹配 Pod 標簽或命名空間標簽。規則指定允許進出所選 Pod 的入口和出口流量。可以設置安全措施以確保每個 Pod 都由 NetworkPolicy 選擇。

在某些組織中，網絡安全和應用程序安全是不同團隊的責任。這可以通過 NetworkPolicies 和 Kubernetes RBAC 在技術上強制執行。只有網絡團隊被授予編輯 NetworkPolicies 的權限，而應用程序團隊僅被授予在選定的命名空間中部署的權限。

最后一條建議：將命名空間視為“內部 API”。由于命名空間最終成為集群內 DNS 名稱的一部分，因此最好通過它提供的服務（例如，“auth”、“database”、“licensing”）來命名命名空間，而不是團隊名稱（“team-green ”、“team-yellow”等）。這種做法還簡化了網絡安全團隊設置 NetworkPolicies 的過程。

結論

簡單性和可理解性是安全的關鍵。雖然安全網格帶來了巨大的好處，但在采用它們之前請考慮更簡單的替代方案。我的經驗是網絡和網絡安全已經足夠復雜。添加另一層可能會使您的平臺團隊不堪重負，并給他們帶來“待命焦慮”。

當然，有許多出色的服務網格特性缺乏更簡單的替代方案，例如多集群安全通信和聯合網絡可觀察性。如果您確實需要更高級的功能，我們希望這篇博文可以幫助您做出明智的決定并接受新增的技術。

Kubernetes 網絡和服務網格都在快速發展。就在最近幾個月，Calico 添加了一個 eBPF 數據平面，并且 Istio 被捐贈給了 CNCF。此類事件可以有利于決策者決定傾向于采用或不采用服務網格。